Comparison
UUID v4 vs UUID v7: Which One Should You Use as a Primary Key?
UUIDs are the universal answer to “how do I generate a unique identifier without coordinating with anyone?” But the different versions are not interchangeable — picking the wrong one for a database primary key can silently wreck your write throughput.
v4 has been the safe default for over a decade because it is fully random. v7, standardized in RFC 9562 (2024), embeds a Unix millisecond timestamp in the leading bits, making IDs time-ordered while keeping the “globally unique without coordination” property. That single change fixes v4's biggest weakness as a database key.
TL;DR
| UUID v4 | UUID v7 | |
|---|---|---|
| Bits of randomness | 122 | 74 (48-bit timestamp + 74) |
| Time-ordered | No — fully random | Yes — leading 48 bits = ms since epoch |
| Sort by insert time | No | Yes |
| B-tree index locality | Poor — scattered inserts | Excellent — mostly appends |
| Collision probability | 1 in 2^122 | 1 in 2^74 per ms |
| Reveals creation time | No (privacy) | Yes (bits are decodable) |
| Standard | RFC 4122 (2005) | RFC 9562 (2024) |
| Library support | Everywhere | Good, still growing |
The options in depth
UUID v4
128 bits of pure randomness.
A v4 UUID has 122 random bits (6 bits are fixed for version + variant). The collision probability is so low that generating a billion per second for a hundred years still gives less than 50% chance of a single collision. That is what people mean when they say “globally unique.”
The randomness is also its weakness for databases. When you insert v4 IDs as the primary key of a B-tree index, each insert lands at a random position — thrashing the cache, splitting pages, and hurting write throughput by 5-10× compared to auto-increment integers on large tables.
Good for
- ·Public-facing IDs where you do NOT want to reveal creation time (private messages, invitations)
- ·Client-generated IDs before a server round-trip (offline-first apps)
- ·Idempotency keys that should be unguessable
Avoid when
- ·You need efficient database inserts and time-based sorting
- ·You want IDs to reflect creation order
UUID v7
Time-ordered UUID with the same uniqueness guarantees for practical use.
A v7 UUID puts a 48-bit Unix millisecond timestamp at the front, followed by 74 random bits. IDs generated close in time sort close together, so the primary-key index is mostly append-only — the same reason auto-increment integers are fast, without giving up global uniqueness.
Databases love v7: Postgres, MySQL, and MongoDB all benchmark 2-5× faster insert throughput compared to v4 on large tables, and range queries by time become trivial (sort by ID = sort by insert time).
Good for
- ·Database primary keys on hot tables
- ·Event / log IDs where time-ordering is naturally useful
- ·Any scenario where auto-increment would be preferred but you need global uniqueness
Avoid when
- ·You do not want to leak creation timestamps (e.g. private message IDs)
- ·Your database driver doesn't support v7 yet (rare in 2025)
Which one should you pick?
→ Is this a database primary key on a hot table?
Use v7. The time-ordered structure gives you 2-5× better insert throughput.
→ Does the ID need to be unguessable from the outside?
Use v4. v7 reveals its creation time — an attacker can enumerate IDs generated in a target window.
→ Do you need to sort or range-query by creation time?
Use v7. Sorting by ID equals sorting by time, no extra column needed.
→ Is this a client-generated ID before hitting the server?
Either works. v7 is slightly better if the client clock is trustworthy; v4 is safer if not.
Common pitfalls
- ⚠Migrating from v4 to v7 does not retroactively reorder existing IDs — the benefit only applies to new inserts.
- ⚠v7 encodes the client's clock. Clock drift between servers can produce out-of-order IDs — usually harmless, but be aware.
- ⚠Because v7 embeds a timestamp, do NOT use it where you rely on IDs being unlinkable to time (e.g. anonymous voting).
- ⚠Some older UUID libraries validate the version nibble and reject v7. Make sure your validation regex accepts version 7.
Frequently Asked Questions
Is UUID v7 standard?
Yes — RFC 9562 was published in May 2024, formally standardizing v6, v7, and v8. Major libraries (uuid in JavaScript, uuid7 in Python, google/uuid in Go) already support it.
Can UUID v7 collide?
Within the same millisecond, there are 74 random bits — collision probability of 1 in 2^74. Even at a million IDs per millisecond, you would need ~30 million years for a 50% collision chance.
What about UUID v1?
v1 is also time-ordered but leaks the MAC address of the generating machine and uses a 100-nanosecond timestamp counted from 1582 — an odd format that v7 replaces with cleaner semantics.
Should I switch existing v4 IDs to v7?
Rarely worth it. Migrating primary keys is high-risk. Use v7 for new tables or when you are already rebuilding the schema.