The database performance angle, specifically
Most relational databases store primary keys in a B-tree index, an ordered structure that performs best when new entries insert at (or near) the end, similar to appending to a sorted list. A traditional auto-incrementing integer key does exactly this — every new row's key is larger than every existing one, so it inserts at the rightmost edge of the index with minimal restructuring.
Random v4 UUIDs break this assumption completely: each new key lands at a random position throughout the index's key range, since there's no ordering relationship between successively generated v4 values. This forces the database to insert into the middle of the index structure repeatedly, causing page splits, fragmentation, and generally worse write throughput and cache locality as a table grows — a well-documented, measurable cost specifically tied to v4's randomness, not UUIDs as a concept.
Why v7 fixes this without sacrificing what UUIDs are for
v7 keeps everything that makes UUIDs useful — no central coordinator needed, generatable independently on any client or server — while fixing the specific index-locality problem: because the leading bits are a timestamp, successively generated v7 UUIDs are (almost always) lexicographically increasing, just like an auto-incrementing integer. New rows insert near the end of the index again, restoring the write-locality benefits that plain v4 keys give up.
| v4 | v7 | |
|---|---|---|
| Insert position in a B-tree index | Random throughout the range | Near the end (like auto-increment) |
| Index fragmentation under high write volume | Significant | Minimal |
| Requires central coordination to generate | No | No |
| Creation time inferable from the key | No | Yes |
When this actually matters in practice
The performance gap between v4 and v7 as primary keys widens specifically at high write volume and large table size — a small table or a low-write-rate application may never notice a meaningful difference either way. This is a scaling concern, not a correctness one: v4 keys work correctly at any scale, they just impose a real, measurable cost on write-heavy systems that v7 avoids.
Common mistakes
- Switching every existing v4 primary key to v7 reflexively, when the actual write volume never justified the migration effort in the first place — this matters most for genuinely high-throughput tables.
- Assuming the fix is "use auto-increment integers instead." That reintroduces centralized coordination (a single sequence generator), which v7 specifically avoids while still getting most of the ordering benefit.
- Forgetting v7 exposes creation time. For tables where the primary key shouldn't reveal when a row was created (e.g., a publicly exposed resource ID), v4's opacity may be worth the index cost.
FAQ
Why do random UUIDs hurt database write performance at scale?
Because they insert at random positions throughout a B-tree index rather than at the end, causing page splits and fragmentation that a sequential key (auto-increment, or time-ordered v7) avoids.
Does v7 require a central server to generate, like auto-increment does?
No — it's still generatable independently on any client or server with no coordination, unlike auto-increment sequences, which need a single authoritative counter.
Is this performance difference noticeable on small tables?
Generally not — the gap widens specifically under high write volume and large table size; small or low-write tables may see no practical difference between v4 and v7.
Generate and compare v4 and v7 UUIDs with the UUID Generator — entirely client-side.