UUID v4 vs v7: Why Databases Are Moving to Time-Ordered IDs

For years, UUID v4 (fully random) was the default choice for primary keys instead of auto-incrementing integers — no coordination needed between servers, effectively zero collision risk. It's also, it turns out, quietly bad for database index performance at scale, which is exactly what UUID v7 was designed to fix.

What a UUID actually is

A UUID (Universally Unique Identifier) is a 128-bit value, conventionally written as 32 hex digits in five dashed groups (xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx). The M digit encodes the version (which generation algorithm produced it), and a few bits encode the "variant." Different versions fill the remaining bits completely differently, which is why v4 and v7 IDs look similar in shape but come from unrelated generation strategies.

UUID v4: fully random

Version 4 sets nearly all 122 remaining bits to cryptographically random values. With that much randomness, the odds of two independently generated v4 UUIDs ever colliding are astronomically small — practically zero for any real-world system. That's the whole appeal: any number of servers can generate IDs independently, with no central counter or coordination, and collisions are a non-issue.

The hidden cost: random IDs scatter across an index

Databases store rows in index structures (commonly B-trees) that perform best when new entries are inserted in roughly sorted order — that keeps new rows physically near each other on disk, which is friendlier to caching and write patterns. A sequential integer ID does this naturally. A fully random v4 UUID does the opposite: each new row's ID lands in a effectively random position in the index, forcing insertions scattered across the entire structure instead of appended near the end. At small scale this doesn't matter; at high insert volume, it measurably hurts throughput and increases index fragmentation and cache misses.

UUID v7: random, but time-ordered

Version 7 restructures the bit layout: the leading bits encode a millisecond-precision Unix timestamp, and the remaining bits are still random (enough to prevent collisions between IDs generated in the same millisecond). The result is a UUID that is simultaneously: still universally unique with no coordination needed, and sortable by generation time — v7 IDs generated later have numerically larger values, so new rows insert in roughly sorted order at the end of an index, just like sequential integers, while keeping every other benefit of a random ID.

Why this matters more as systems scale

For a small side project, v4 vs v7 makes no practical difference — the index-fragmentation cost only shows up under sustained high-volume inserts. Large-scale distributed systems (the kind with multiple database shards, high write throughput) are exactly where this trade-off starts costing real performance, which is why v7 has been gaining adoption specifically among database-heavy backend teams, not because v4 was ever "wrong," but because v7 is strictly better for this specific access pattern with no real downside.

v1: the older time-based version, with a privacy problem

UUID v1 also encodes a timestamp, but pairs it with the generating machine's MAC address — which means a v1 UUID can leak which physical machine (and roughly when) generated it, a real privacy and information-disclosure concern that's part of why v1 fell out of favor for anything user-facing. v7 achieves the same time-ordering benefit using random bits instead of a hardware identifier, sidestepping that leak entirely.

Spellkit's UUID Generator generates v4, v7, and v1 UUIDs — cryptographically random, right in your browser — so you can pick the version that matches what your database or system actually needs.