UUID v4 vs v7: which should you use?
v4 is 122 bits of pure randomness. v7 (RFC 9562) leads with a Unix-millisecond timestamp, so IDs generated later sort later — which is exactly what database indexes want.
At a glance
| UUID v4 | UUID v7 | |
|---|---|---|
| Structure | Random | Timestamp + random |
| Sortable by creation | No | Yes |
| DB index locality | Poor (random inserts) | Good (append-like) |
| Leaks creation time | No | Yes (by design) |
| Standard | RFC 4122 | RFC 9562 (2024) |
Why v7 wins for database keys
Random v4 keys insert all over a B-tree index, causing page splits and cache misses at scale. v7's timestamp prefix makes inserts roughly sequential — the same property that makes auto-increment fast, without the coordination problem.
Pick v4 only when IDs must not reveal creation time or ordering — password-reset tokens, invite codes, anything where the timestamp is information leakage.
Tools used in this guide
Related guides
UUID v4 vs v7: which should you use? — FAQ
v7 — its timestamp prefix keeps index inserts nearly sequential, avoiding the fragmentation random v4 keys cause.