UUID v4 vs v7: Which Version Should You Use?

Here's a claim that'll ruffle feathers: the default advice to 'just use UUID v4 everywhere' is quietly slowing down databases, and it has been for years. v4 is a fine identifier and a poor primary key, and the newer v7 fixes the poor part without giving up what made UUIDs useful. If you've ever wondered why your table with UUID keys writes slower than one with plain integers, this is why.

The problem hiding in random keys

A UUID is a 128-bit identifier you can generate anywhere without asking a central authority. Version 4 builds almost the whole value from randomness — 122 random bits. That randomness is exactly what makes it a great unique value and a troublesome ordered one.

Databases store primary keys in a sorted structure (usually a B-tree). When each new key is random, it lands in an unpredictable spot in that sorted order. Rows don't append to the end; they wedge into the middle, over and over.

Why that costs you

Random inserts mean the index is constantly reorganizing:

• Page splits. A full index page that receives a mid-order insert splits in two, doubling write work.
• Cache misses. The next insert touches a different part of the index than the last, so the useful pages rarely stay in memory.
• Fragmentation. The index bloats and scans get slower over time.

On a small table you'll never notice. On a table taking thousands of inserts a second, v4 as the clustered key is a measurable tax.

The raffle-ticket analogy

Picture two ways of handing out tickets. Version 4 is a bowl of lottery numbers: every ticket is random, so if you try to file them in order you're forever slotting new ones between existing ones. Version 7 is a roll of numbered raffle tickets: they still each identify one person uniquely, but they come off the roll in time order, so filing is just 'put it on the end.'

That's the whole idea behind v7. It reserves the leading bits for a millisecond Unix timestamp and fills the rest with randomness. You keep uniqueness and un-coordinated generation; you gain sortability.

What v7 changes, concretely

• Time-ordered. Sorting v7 UUIDs sorts them roughly by creation time — handy for pagination and range queries.
• Index-friendly. New keys append near the end of the B-tree, so you avoid most page splits.
• Still unique and decentralized. Generated locally, no coordination, negligible collision odds — the properties that made you choose UUIDs in the first place.

The trade-off: because the timestamp is embedded, a v7 UUID leaks its creation time to anyone who can read it. Usually harmless, occasionally not.

When v4 is still the right call

v7 isn't a blanket replacement. Reach for v4 when:

• The ID is public-facing and you don't want it to reveal when a record was created or roughly how many exist.
• You need a value with no embedded structure — a pure random token. For that, a random string generator or a Nano ID may fit even better.
• You're generating IDs that never become a clustered database key, so insert ordering is irrelevant.

How to choose in one line

Ask what the ID's main job is. Database primary key you insert a lot? v7. Opaque public identifier that should hide order and timing? v4. If you just need a handful to test with, the UUID Generator produces both v4 and name-based values on demand, and the deeper version tour lives in what is a UUID.

The takeaway

v4 versus v7 isn't old-versus-new; it's random-versus-time-ordered, and the right pick follows the ID's role. Use v7 when the identifier lives in a database index and insert performance matters. Use v4 when unpredictability and hiding creation order matter more than sort speed. Same 128 bits, same decentralized generation — you're just choosing whether the first few bits tell a story or keep a secret.