UUID v4 vs UUID v7
Both are 128-bit identifiers defined by RFC 9562 (which obsoleted RFC 4122 in 2024). Version 4 is essentially all-random; version 7 puts a millisecond timestamp in the high bits so IDs sort by creation time. The difference matters most for database primary keys.
| Aspect | UUID v4 | UUID v7 |
|---|---|---|
| Composition | 122 random bits | 48-bit timestamp + 74 random bits |
| Sortable by time | No | Yes |
| Best for | General unique IDs | Database primary keys |
| Reveals creation time | No | Yes (millisecond) |
| Defined in | RFC 9562 | RFC 9562 |
What changed with RFC 9562
RFC 9562 kept v1–v5 and added v6, v7, and v8. Version 7 is the new recommendation for most systems that need sortable, unique keys, because it combines a Unix-millisecond timestamp with random bits for uniqueness.
Why v7 helps databases
Random v4 keys scatter inserts across a B-tree index, causing page splits and poor cache locality. Time-ordered v7 keys append near the end of the index, keeping inserts fast and the index compact — the same benefit auto-increment integers give, without a central sequence.
When v4 is still the right choice
Use v4 when you specifically do not want the creation time to be inferable from the ID, or when ordering is irrelevant and you want maximum entropy. For public-facing identifiers where leaking a timestamp is undesirable, v4 remains the safer default.
Frequently Asked Questions
Is UUID v7 better than v4?
For database primary keys, yes — v7's time ordering keeps indexes efficient. For opaque public IDs where you don't want to leak timestamps, v4 is better.
Are v4 and v7 both collision-resistant?
Yes. Both include enough random bits that collisions are astronomically unlikely at practical scale.
Does the generator support v7?
The generator produces RFC 9562 version-4 UUIDs. For time-ordered keys, use a v7 library on your backend; this guide explains when that is worthwhile.