UUID v4 vs v7: which one should you use in 2026?
v4 is random. v7 is time-ordered. That one difference decides your database performance. Here's when each wins, and why v7 is quietly becoming the default.
What v4 and v7 actually are
A UUID is 128 bits. Different versions use those bits differently:
- v4 — 122 random bits, 6 bits reserved for the version and variant markers. Fully random, unpredictable, uniformly distributed across the 128-bit space.
- v7 — 48 bits of Unix millisecond timestamp at the front, then 74 random bits. Two IDs generated a second apart sort in the order they were created.
Both are RFC-compliant (v7 was standardized in RFC 9562 in 2024). Both look identical to a human — 36 characters with hyphens — but their behavior in a database index is very different.
Why time-ordering matters for databases
Most databases store rows in an index ordered by primary key. When you insert a row, the database finds the right leaf page and writes there. With random keys (v4), every insert lands in a random page — the working set is huge, cache hit rate collapses, and you fragment the index badly.
With time-ordered keys (v7), consecutive inserts land in the same page. The index grows sequentially — one hot page at the end, all older pages cold. Postgres, MySQL, and SQL Server all benefit; the effect is most dramatic on Postgres with B-tree indexes.
Benchmarks published by Cloudflare and others show 2-4x insert-throughput improvements swapping v4 for v7 on write-heavy tables. That's real money on real workloads.
When v4 is still the right answer
Three cases:
1. You need unpredictability. A password-reset token, an unlisted-share URL, an anti-enumeration ID. v7 leaks the creation time — an attacker can guess adjacent IDs. Use v4 (or better, a random 32-byte token).
2. Cross-shard uniqueness matters more than sort order. Fully random IDs collide less catastrophically in distributed systems where two nodes might generate the same millisecond timestamp.
3. You already have v4 everywhere. Mixing v4 and v7 in the same column works fine (both are valid UUIDs) but you lose the sort-order benefit until you're mostly v7.
v1, v6, ULID — why not those?
- v1 puts a MAC address in the ID. It leaks server identity and has clock-back-in-time bugs. Skip it.
- v6 rearranges v1's bytes so they sort chronologically. Better than v1, but v7 dropped the MAC address requirement and is simpler.
- ULID and KSUID are pre-standard time-ordered ID formats. Great, but v7 is the standard now — pick v7 unless you're already using ULID at scale.
Generating them safely
Both v4 and v7 need cryptographic randomness — not Math.random. UUID Generator uses window.crypto.getRandomValues, the same source browsers use for TLS keys, and generates locally so IDs never leave your device.
For bulk seeding (test data, migrations), the tool generates up to 1,000 at once — enough for most fixture files without needing to wire up a script.
The bottom line
Default to v7 for anything used as a database primary key or sort-order field. Fall back to v4 anywhere the ID is exposed to an untrusted party or needs to look random. Both are one function call away — the choice is about downstream behavior, not implementation cost.
Related tools:
- Timestamp Converter — to decode a v7 back to its creation time.
- Hash Generator — when a shorter opaque ID would do (e.g. SHA-256 truncated).