Every UUID looks like the same random-looking string of hex characters and dashes, but not all UUIDs are built the same way underneath. UUID v4 is pure randomness, while UUID v7 deliberately bakes in a timestamp so values sort in roughly the order they were created. That difference sounds minor until it hits database performance at scale, where it becomes one of the more consequential choices in a schema design.
- UUID v4 is 122 bits of pure randomness; UUID v7 embeds a 48-bit millisecond timestamp plus random bits
- v7 values sort roughly in creation order; v4 values are randomly scattered with no inherent order
- As database primary keys, v4 causes index fragmentation from random inserts; v7 mostly appends, keeping indexes efficient
- v7's timestamp is readable by anyone who sees the value, which v4 avoids entirely
- Both are equally safe from accidental collisions in practice, the difference is about structure, not uniqueness
What’s Actually Different Under the Hood
A UUID is always 128 bits, formatted as 32 hex characters split into five dash-separated groups. Where v4 and v7 diverge is how those bits are chosen.
UUID v4 sets aside a few fixed bits to mark the version and variant, and fills essentially everything else, 122 bits, with random data. There’s no structure to exploit and no information encoded beyond “this is a version 4 UUID.”
UUID v7 starts with a 48-bit Unix timestamp in milliseconds, taking up the first part of the value, followed by random bits for the rest. Because the timestamp comes first, sorting UUID v7 values as plain strings sorts them in roughly chronological order too, something that’s simply not possible with v4’s fully random layout.
Why This Matters for Database Primary Keys
The structural difference isn’t just trivia, it directly affects how a database’s index behaves as rows are inserted. Most relational databases store primary key indexes as B-trees, which perform best when new values are inserted at or near the end, similar to appending to a sorted list.
A random UUID v4 used as a primary key inserts at an essentially random position in that index every single time, since there’s no relationship between one value and the next. At small scale this is invisible, but as a table grows, this causes page splits and index fragmentation, which slows down writes and bloats the index on disk. UUID v7, because its timestamp prefix keeps values roughly increasing, mostly inserts near the end of the index instead, behaving much closer to an auto-incrementing integer ID while still keeping the collision resistance and decentralized generation that made UUIDs appealing over integers in the first place.
When v4’s Randomness Is Actually the Right Choice
None of this makes v4 obsolete. For identifiers where hiding creation time matters, like password reset tokens, API keys, or anything where an attacker guessing “this was likely issued around the same time as that other one” would be useful information, v4’s lack of any embedded timestamp is a genuine security property, not just an omission.
v4 is also the simpler default when the value in question isn’t a high-volume database primary key at all, for example a one-off identifier generated client-side for a UI element, where index performance never comes into play and there’s no reason to reach for anything more specialized.
Quick Comparison
| UUID v4 | UUID v7 | |
|---|---|---|
| Structure | Fully random | Timestamp prefix + random |
| Sortable by creation time | No | Yes, roughly |
| Leaks creation time | No | Yes |
| Database index performance at scale | Degrades with fragmentation | Stays efficient, mostly sequential |
| Best for | Security tokens, non-indexed identifiers | Primary keys, event logs, sortable records |
Generating Either Version
Both versions follow specific bit-layout rules that are easy to get subtly wrong by hand, particularly the version and variant bits that mark a UUID as v4 or v7 in the first place. The UUID Generator produces correctly formatted values for either version on demand, so there’s no need to hand-roll the bit manipulation or accidentally generate a malformed identifier.
The short version
UUID v4 and UUID v7 are both valid 128-bit UUIDs, but v4 is entirely random while v7 leads with a timestamp, making v7 values sort roughly in creation order. That ordering translates directly into database index performance: v4 as a primary key causes fragmentation from random inserts at scale, while v7 mostly appends, staying efficient. Reach for v7 on high-volume primary keys and sortable records; stick with v4 when hiding creation time matters, like security tokens, or when the value never touches a large indexed table in the first place.
