UUID v4 vs v7: Which One Should You Use?
Published
For years, version 4 was the default choice for UUIDs. RFC 9562, published in 2024, standardized version 7, which puts a timestamp at the start. Here's what changes and which one fits your case.
Two ways to build a unique ID
Both versions are 128-bit identifiers written as 32 hexadecimal digits, like 0193c4a0-7e2b-7c3d-9f1e-5a6b7c8d9e0f. They differ in what those bits contain.
- Version 4 is almost entirely random: 122 random bits, plus 6 bits that mark the version and variant.
- Version 7 starts with a 48-bit Unix timestamp in milliseconds, followed by 74 random bits. The first characters therefore grow over time.
You can generate both, and check the version of any UUID, with the UUID Generator.
Why v7 is better for databases
Most databases store primary keys in a B-tree index, which works best when new keys arrive in order. Random v4 keys land in arbitrary places in the index, so inserts touch pages all over it, the index fragments and caching becomes less effective as tables grow.
v7 keys are created in increasing order, so new rows are appended near the end of the index, much like an auto-incrementing number. You keep the benefits of UUIDs, such as generating IDs on any server without coordination, while avoiding most of the performance cost.
As a bonus, sorting by a v7 ID roughly sorts by creation time, and you can read the creation moment straight from the ID.
When v4 is still the right choice
The timestamp in v7 is visible to anyone who sees the ID. That's harmless for most records, but it can leak information: when an account was created, or how quickly orders are being placed.
- Use v4 for identifiers shown to the public where timing is sensitive.
- Use v4 when IDs must not reveal the order in which things were created.
- Use v4 when the system that stores them gains nothing from ordering, such as a key-value store.
What neither version is for
A UUID is an identifier, not a secret. Even though v4 is generated from secure randomness, don't use UUIDs as passwords, API keys or password-reset tokens: they are often logged and shared, and their format is predictable. Use a dedicated random token generator for those.
Quick decision guide
- Primary keys in a relational database: v7.
- Event and log IDs you want to sort by time: v7.
- Public IDs where creation time shouldn't be visible: v4.
- Existing systems that already use v4: keep v4 unless index performance is a real problem.