UUID v4 vs UUID v7: Choosing the Right Identifier

For two decades, UUID v4 was the default. Now UUID v7 is quietly replacing it for database primary keys — and there's a good reason. If you're still reaching for v4 by reflex, it's worth understanding when the newer version is the better choice.

A quick UUID refresher

A UUID (Universally Unique Identifier) is a 128-bit value designed to be unique across space and time without coordination. The defining feature: any machine can generate one, right now, and it'll still be unique.

UUIDs are usually displayed as 32 hex digits in five groups separated by dashes: xxxxxxxx-xxxx-Vxxx-Vxxx-xxxxxxxxxxxx. The position of the version digit (V) tells you which UUID variant created it.

UUID v4: random

UUID v4 is 122 bits of randomness (with 6 bits reserved for version and variant). The chance of collision is astronomically small — you'd need to generate billions per second for many years before you'd expect to see a duplicate.

v4 is great for: session tokens, API keys, public-facing IDs where unpredictability matters, anywhere the ID will be displayed or shared and you don't want users to guess neighboring values.

UUID v7: time-ordered

UUID v7 starts with a 48-bit Unix timestamp in milliseconds, followed by random bits. The first part of the UUID encodes when it was created — so identifiers naturally sort by creation time.

Two UUIDs generated even a millisecond apart will sort in the order they were created. This is enormously useful for database primary keys.

Why v7 is better for database keys

Most databases use B-tree indexes for primary keys. B-trees stay balanced and fast when new keys are inserted at the end (or in approximate order). Random UUID v4 inserts cause:

• Index fragmentation: new keys land in random positions, splitting pages constantly.
• Cache thrashing: recently-inserted rows aren't adjacent in the index, so the page cache misses more often.
• Slower bulk inserts: each insert is essentially a random write to disk.

UUID v7 fixes all of this. Inserts go to the end of the index. Adjacent rows in time are adjacent in the index. Bulk inserts are sequential writes. In benchmarks, this translates to 2–10× faster write throughput on large tables.

When to stick with v4

• Security-sensitive identifiers: session tokens, password reset tokens, API keys. v7's timestamp prefix makes IDs partially predictable, which is a non-issue for primary keys but problematic for secrets.
• Public IDs you don't want to leak creation time: if knowing when a record was created is sensitive (say, billing records), use v4.
• Maximum entropy needs: v4 has 122 bits of randomness; v7 has only 74 bits in the random portion. Both are way more than enough for uniqueness, but v4 is the right answer for cryptographic uses.

UUID vs auto-incrementing integer

Auto-incrementing integers are smaller (4 or 8 bytes vs UUIDs' 16) and faster. Use them when:

• You have a single source of truth — no need for cross-system uniqueness.
• You don't mind exposing “there are 47,000 users” via sequential IDs.
• Storage and index size matter — UUIDs are 4× larger than 32-bit ints.

Use UUIDs (v7 for keys, v4 for tokens) when:

• You generate IDs across multiple services or databases without coordination.
• You don't want to leak record counts.
• You need to merge data from different systems without ID conflicts.