UUID v4 vs v7: Which Should You Use for IDs in 2026?
UUID v4 is random; v7 is time-ordered. A practical guide to choosing a UUID version for database keys vs public IDs — and why v7 fixes the index fragmentation v4 causes.
You need a unique identifier and you've narrowed it to a UUID. Good — but "UUID" isn't one thing. Picking v4 (random) when you wanted v7 (time-ordered) can quietly fragment your database indexes; picking v7 when you wanted v4 can leak roughly when a record was created. The two are easy to tell apart once you know what each optimizes for.
What the versions actually encode
A UUID is 128 bits. The version number just describes how those bits are filled:
| Feature | UUID v4 | UUID v7 |
|---|---|---|
| Source of bits | 122 random bits | 48-bit ms timestamp + random |
| Sortable by creation time | No | Yes |
| Leaks creation time | No | Yes |
| Database index locality | Poor (random inserts) | Good (sequential inserts) |
| Guessable / enumerable | No | No |
| Standardized | RFC 4122 | RFC 9562 (2024) |
The key difference is the timestamp prefix in v7. Two v7 IDs created moments apart sort next to each other; two v4 IDs are random noise relative to each other.
Generate v4 (random) or v7 (time-ordered) UUIDs — bulk-generate and copy in one click.
Why v4 hurts database indexes (the hidden cost)
This is the issue most teams discover too late. When you use a random v4 UUID as a primary key, every insert lands at a random position in the B-tree index. The database can't simply append; it scatters writes across the whole index, causing page splits, fragmentation, and a cache that's constantly missing.
UUID v7 fixes this by design. Because the high bits are a timestamp, new IDs are monotonically increasing — inserts append to the end of the index, just like an auto-increment integer. You keep the benefits of UUIDs (no central counter, generate IDs anywhere, no collisions across services) without the write-amplification penalty.
Why you'd still choose v4
v7's timestamp is a feature for databases and a leak for public-facing IDs. If a UUID appears in a URL, an API response, or an email link, a v7 ID tells anyone holding it roughly when the record was created — and lets them estimate how fast your IDs are being minted (a crude business-metrics leak).
So the split is clean:
- Internal primary keys, sortable IDs, anything index-heavy → v7.
- Public, exposed, unguessable IDs where metadata leakage matters → v4.
A common pattern is to use both: a v7 primary key internally, and a separate v4 "public id" for anything exposed to users.
What about v1 and v5?
- v1 embeds a timestamp and the machine's MAC address — it can leak hardware identity and isn't recommended for new systems. v7 is its modern replacement.
- v5 is deterministic: it hashes a namespace + name, so the same input always yields the same UUID. Useful for derived/idempotent IDs (e.g., a stable ID for a known resource), not for general unique keys.
For brand-new code in 2026, the decision is almost always v4 vs v7.
Quick decision guide
- Is it a database primary key?
Yes → v7. The sequential-insert benefit compounds as the table grows.
- Will the ID be exposed publicly?
Yes, and creation time/volume should stay private → v4.
- Do you need the same input to always map to the same ID?
Yes → v5 (deterministic, namespace-based).
- Still unsure?
Default to v7 for internal IDs, v4 for public ones. Generate either above and move on.
Related tools
Need a different kind of unguessable string? Generate high-entropy passwords and keys.
Seed a database with realistic test records, UUIDs included.
More developer utilities live in the Developer Tools hub.
Related reading
Recommended tools for this topic
Explore focused tools and use-case pages related to this article.