Why UUID v7? Time-Ordered UUIDs Explained

For two decades, UUID v4 was the default. Then engineers started using them as database primary keys at scale and discovered a quiet performance disaster — random UUIDs are terrible for B-tree indexes. UUID v7, standardised in RFC 9562 in May 2024, fixes this without giving up the things that made UUIDs useful in the first place.

The Problem with Random UUIDs

A v4 UUID is 122 random bits. When you insert a row keyed on a v4 UUID, the database has to find the right spot in the B-tree index — and because the value is random, that spot is somewhere unpredictable. Every insert touches a different leaf page. Pages get split. Caches miss. Write amplification balloons.

For a low-traffic table this is invisible. At scale, it's the difference between an index that fits in RAM and one that thrashes the disk. Engineers at Percona, Stripe, and Shopify all wrote about this in the 2010s — and the workaround was usually some custom flavour of "COMB UUID" that prefixed a timestamp to a UUID to fake sortability.

What UUID v7 Does Differently

A v7 UUID puts the timestamp first — explicitly, by spec. The structure is:

tttttttt-tttt-7xxx-yxxx-xxxxxxxxxxxx
\__________/  \_______________/
   48 bits         74 bits
 Unix ms ts        random data

The first 48 bits encode a Unix timestamp in milliseconds — enough range to last until the year 10889. The next 4 bits are the version (7). The remaining 74 bits are cryptographically random, with 2 bits reserved for the variant.

Because the timestamp is in the high-order bits, sorting v7 UUIDs lexicographically gives you chronological order. Two UUIDs generated one second apart compare predictably; two generated in the same millisecond fall back to the random tail and almost certainly never collide.

Why This Fixes the Database Problem

New v7 UUIDs are always larger than older ones (at millisecond resolution). That means inserts always go to the right edge of the B-tree index — exactly where auto-increment IDs go. No page splits in the middle of the index. No cache misses on cold pages. Insert performance approaches that of a bigint primary key.

You also get a free secondary benefit: queries like "recent records" or "records from this hour" can use the primary key directly without a separate timestamp index.

What About ULID and KSUID?

Before UUID v7 was standardised, ULID (2016) and KSUID (Segment, 2017) solved the same problem with non-standard formats. They were good ideas — but they required your tooling to understand a new format. PostgreSQL, MySQL, MongoDB, and every UUID library on the planet already speak UUID. RFC 9562 ratifies what ULID got right and bakes it into the standard.

If you're starting fresh in 2026, use UUID v7. If you have a working ULID deployment, there's no urgency to migrate — but new tables should default to v7.

What Did v7 Give Up?

Two things, both minor:

• Slightly less randomness. v4 has 122 random bits; v7 has 74. Both are far beyond any realistic collision risk, but v7 is technically less unpredictable. For session tokens or password reset codes where guessing matters, prefer v4.
• Creation time is observable. Anyone with a v7 UUID can extract the millisecond it was generated. Usually fine. If you don't want that — for example, anonymising a public ID — use v4.

Adoption Status

As of 2026, UUID v7 is supported natively or via well-maintained libraries in every major language: PostgreSQL 17 added it as a built-in function, MySQL has it via UDFs, and Node.js, Python, Go, Rust, and Java all have first-class library support. ORMs (Prisma, Hibernate, SQLAlchemy) treat v7 as a drop-in replacement for v4 in primary key columns.

The Short Version

Use UUID v7 for anything that gets indexed — primary keys, event IDs, log entries, anything chronological. Use v4 for anything where randomness is the point — tokens, secrets, idempotency keys, anonymous identifiers. Most systems need both.