UUID v4 vs v7 vs Others — Which to Use
UUIDs come in eight versions. For new systems, the answer is almost always v7 (RFC 9562, December 2024). This guide explains why, when to use the others, and how the format trade-offs play out at database scale.
The eight versions in 30 seconds
RFC 9562 (Dec 2024) defines UUID versions 1-8. Five are widely used; three (v3, v5, v8) are niche.
| Version | Source | Sortable? | Use it? |
|---|---|---|---|
| v1 | timestamp + MAC address | By time, sort of | No — leaks the MAC |
| v3 | MD5 of namespace+name | No | Niche (deterministic IDs) |
| v4 | 122 bits of randomness | No | Yes for non-DB-key cases |
| v5 | SHA-1 of namespace+name | No | Like v3 but SHA-1 instead of MD5 |
| v6 | v1 reordered to be sortable | Yes | Skip — v7 is better |
| v7 | 48-bit unix-ms + 74 random | Yes | Yes — default for new DB keys |
| v8 | Custom (defined by you) | Maybe | Niche (custom embedding) |
Why v7 is the right default
v4 was the right answer for fifteen years. It's simple, has 2^122 possible values (collision practically impossible), and cryptographically random — predictable only if your RNG is broken.
The downside: v4 IDs are not sortable. They have no temporal structure. When you use v4 as a primary key in an indexed database table, every insert lands at a random spot in the B-tree. The pages that hold the index split, repaginate, and fragment continuously. On large write-heavy tables this is measurable: insert latency degrades over time, page caches evict more often, and replication latency rises.
v7 fixes this. The first 48 bits of a v7 UUID are a Unix millisecond timestamp, big-endian. The remaining 74 bits are random. So v7s sort by creation time naturally. New rows append to the right of the B-tree (the "hottest" page is always the most recent). Inserts stay fast as the table grows. Retain the collision resistance of v4 (74 bits of entropy is still 2^74 ≈ 1.9×10²² values per millisecond).
Cassandra, Postgres, MySQL all benefit from this when v7 is used as a clustered/primary key. SQLite and DynamoDB benefit similarly.
When v4 still wins
- You don't want sequence leakage. v7 IDs reveal when they were created. If that's confidential (e.g. consecutive customer IDs leak signup velocity to competitors), use v4.
- You're not using it as a database key. Session tokens, file names, ephemeral handles — sortability doesn't help. Just use v4.
- Your database doesn't care about insertion order. Hash-based key-value stores don't have B-trees that need to be balanced. UUID sortability is irrelevant.
v3 and v5 — namespace UUIDs
v3 (MD5) and v5 (SHA-1) deterministically hash a namespace UUID + a name string into a UUID. Useful when you need stable IDs for things that have natural names: v5(DNS, "example.com") == v5(DNS, "example.com") always. Use v5 over v3 (MD5 is broken). Use them only when you actually need the determinism — otherwise prefer v4 or v7.
JustKit's UUID generator
The JustKit UUID generator supports v4 and v7 with bulk generation up to 1000 at a time. v4 uses crypto.randomUUID() where available (Chrome 92+, Node 14+) and falls back to a manual implementation using crypto.getRandomValues. v7 is always implemented manually since browser support is still rolling out.