A short investigation, with sliders. The honest answer hides under three different definitions of search, and the version of the UUID matters less than the workload looking at it.
“Demonstrably” is doing a lot of work in that sentence. A UUIDv7 is the same 128 bits as a v4; the bits are just arranged so that the timestamp goes first. Whether that arrangement makes search faster depends entirely on what you are searching for.
For point lookups by primary key, the answer is mostly{' '} not really. A B-tree of a hundred million rows has the same height regardless of whether the keys arrived in order or in chaos; you descend three or four levels and find the row. For everything else a database does — inserts, recent-data reads, time-range scans, vacuuming, index maintenance — v7 wins, sometimes by a startling margin, and a careful look reveals that this is essentially a story about one thing: where new rows land.
The numbers in the experiments below come from a real B-tree and a real LRU buffer cache running in your browser. You can open the simulator's source under §IV and read it. It implements Postgres' asymmetric rightmost-leaf split, so v7's monotonic inserts get to use the same fastpath the real database uses.
The version of the UUID is a property of the keys. The performance you measure is a property of the workload. The two are easy to confuse.
Both versions are sixteen bytes. The bits that change are the ones that used to be random. In v7, the leading 48 bits are a Unix millisecond timestamp; the rest is randomness with a four-bit version marker tucked in.
Same width on disk, same hash quality, same uniqueness guarantee. The only thing v7 trades away is the uniformity of where a new key lands when you sort the keyspace — and that, it turns out, is exactly the property that B-tree indexes care about.
Below, two real B-trees, one fed v4 keys and one fed v7. Each insert finds the leaf page that should contain it (binary search on page boundaries) and adds the row; if the page is full, the tree splits it. Press play and watch: with v4 keys, splits happen everywhere. With v7 keys, the tree only ever grows on its right edge.
Run it for a few thousand rows. The v4 index converges to about 70% page fill — a famous result from random-tree analysis: pages split at random points and never quite re-fill. The v7 index pins to{' '} 100% fill on every page except the rightmost, because v7 keys always overflow the rightmost leaf and the B-tree's asymmetric rightmost split leaves the old page full and starts a fresh one with just the new key.
Same number of rows; the v4 tree ends up with roughly{' '} 40% more pages. That index lives in the buffer cache, gets vacuumed, gets walked on every insert, and gets shipped to standbys. A smaller index is a faster index, even before any query runs.
The asymmetric rightmost split isn't something we invented for
this simulator — it's how Postgres' _bt_findsplitloc
actually behaves when it detects monotonic inserts. v7 keys hit
this fastpath; v4 keys can't. The simulator above implements the
same logic.
Now the same indexes, but read instead of written. Everything below is computed by a real B-tree and a real LRU buffer cache running in your browser — no formulas, no multipliers, no fudge factors. Pick a workload, watch the verdict shift.
{`class LRU {
constructor(capacity) { this.capacity = capacity; this.map = new Map(); }
touch(id) {
if (this.map.has(id)) {
this.map.delete(id); this.map.set(id, 1); return true; // hit
}
if (this.map.size >= this.capacity)
this.map.delete(this.map.keys().next().value); // evict LRU
this.map.set(id, 1); return false; // miss
}
}
class BTreeSim {
insert(key, rowIdx) {
const idx = this.findPageIdx(key); // binary search
const page = this.pages[idx];
/* sorted-insert key into page.keys */
if (page.keys.length > this.capacity) {
// Postgres-style asymmetric rightmost split:
const isRightmost = (idx === this.pages.length - 1);
const insertedAtEnd = (i === page.keys.length - 1);
const splitAt = (isRightmost && insertedAtEnd)
? page.keys.length - 1 // leave old page full
: (this.capacity + 1) >>> 1; // 50/50 otherwise
/* split page.keys at splitAt, append new page */
}
}
}
// Inserts: for each row t, v4Key=Math.random(), v7Key=t/N + tinyNoise.
// Cache state: replay every page touched during inserts through an LRU.
// Lookups: for each query, find pageOf[t], cache.touch() it, count hits.
// Cost = hits × 1 + misses × 80 (RAM vs random NVMe read)`}
)}
Three observations earn most of the answer to the original question. First, random point lookups are essentially a tie — you can verify it on the first tab. The B-tree height is the same for both indexes, the hit rate is the same (whatever fraction of pages your cache covers), and the cost barely differs. v7 wins by a hair only because its index is smaller.
Second, recent point lookups favor v7 dramatically. The rows you're looking up live on the rightmost pages of the v7 tree — exactly the pages that were last touched by inserts and therefore still resident in the cache. In v4 those same rows are scattered randomly across hundreds of pages, none of them preferentially warm.
Third, batch recent fetches favor v7 spectacularly. Imagine you have a list of fifty recently-created event ids and you need to load each row to render a feed. In v7 those fifty ids cluster onto a handful of contiguous, hot pages — the database reads maybe ten distinct pages, all from cache. In v4 the fifty ids land on something like fifty distinct pages, most of them cold. The cost ratio routinely runs into the triple digits.
Depends on what you’re searching for. Here is the honest scoreboard of the question as asked.
bigserial/identity.{' '}
v7 is a compromise: client-generatable, distributed-friendly,
shardable. A 64-bit serial is half the size and just as
monotonic. If you can use a serial, you’ll beat v7 on every
metric. v7’s niche is exactly the case where you can’t.
The original question asked whether search is faster. The right reframing is: which searches, against{' '} which data, at which point in its lifecycle. v7 is doing one thing for you — it’s clustering by time — and you can predict its wins by asking whether your workload cares.
The simulation above is a model. Below is a script that actually
measures it on Postgres 17+, which ships uuidv7() as
a built-in. Run it on your own machine; the numbers will surprise
you most when the working set exceeds RAM.
For older Postgres, the pg_uuidv7 extension or a
short PL/pgSQL function gives you the same generator. The shape
of the result is the same.
Pick the key that makes the index a graph of your access pattern. v7 is what that looks like when your access pattern is time.