UUID v4 vs v7: random or time-ordered?
Both are 128-bit unique identifiers, but they behave very differently inside a database index. If you are choosing a primary-key strategy, this is the comparison that matters.
| UUID v4 | UUID v7 | |
|---|---|---|
| Composition | 122 random bits | Unix-ms timestamp + random bits |
| Sortable by time | No | Yes |
| Index locality | Poor (scatters writes) | Excellent (sequential) |
| Collision risk | Negligible | Negligible |
| Leaks creation time | No | Yes (timestamp is embedded) |
| Best for | Tokens, opaque IDs | Database primary keys |
Why v4 hurts database inserts
Random v4 keys land in random positions of a B-tree index. On a large table this causes page splits and cache misses on every insert, slowing writes and bloating the index.
v7 puts a millisecond timestamp in the high bits, so new rows are appended near each other — the same locality you get from an auto-increment integer, without coordination.
The trade-off: privacy
v7’s timestamp is its strength and its weakness. Anyone with a v7 UUID can read roughly when it was created. For opaque public identifiers where that leak matters, prefer v4.
The verdict
Reach for v7 by default for database primary keys — you get uniqueness and index-friendly ordering. Use v4 for tokens and public IDs where you do not want to leak timing. Generate either in the UUID Generator.
Frequently asked questions
- Is UUID v7 better than v4 for primary keys?
- Usually yes. Its time-ordered prefix keeps inserts sequential in the index, avoiding the write amplification random v4 keys cause on large tables.
- Does UUID v7 leak information?
- It embeds a creation timestamp, so it reveals roughly when the ID was generated. v4 does not.
- Are v7 collisions more likely than v4?
- No. v7 still includes enough random bits per millisecond that collisions are effectively impossible at normal generation rates.
Try it yourself
Free, in-browser tools for everything above.