UUID v4 vs v7: does it matter?

UUID v4 is the version most people mean when they just say "UUID" — 122 bits of randomness, formatted as the familiar 8-4-4-4-12 hex string. It's simple, well-supported everywhere, and the collision probability is low enough not to worry about in practice.

The catch with v4 shows up at scale, specifically as a database primary key. Because the value is fully random, new rows get inserted at random points throughout an index rather than at the end. For B-tree indexes (used by most relational databases), that causes page splits and fragmentation, which measurably hurts write performance and index locality once a table gets large.

UUID v7 was designed to fix exactly this. It embeds a millisecond-precision timestamp in the leading bits, with the remaining bits still randomized. That means v7 values generated close together in time sort close together in value — which restores the mostly-sequential insert pattern that B-tree indexes are efficient at, similar to what an auto-incrementing integer ID gives you, while still being globally unique and not revealing a predictable sequence like `1, 2, 3` would.

In short: if you're generating IDs for something that will become a large, frequently-written database table, v7 is generally the better default now. If you're generating a one-off identifier — a temp file name, a request ID, a feature flag key — the difference is irrelevant and v4 is perfectly fine, which is why it's still the more common general-purpose choice (including in the UUID generator on this site).