UUID v4 vs v7 — Which Should You Use?
Both are random, both are globally unique. The difference is one word: sortable. Here's when that matters.
Side-by-Side Comparison
| Property | UUID v4 | UUID v7 |
|---|---|---|
| RFC standard | RFC 4122 (2005) | RFC 9562 (2024) |
| Structure | 122 bits random | 48-bit ms timestamp + 74 bits random |
| Sortable by creation time | No | Yes |
| Randomness bits | 122 bits | 74 bits |
| Privacy (no timing leak) | Yes | Leaks creation timestamp |
| Database B-tree performance | Poor (random inserts → fragmentation) | Good (sequential inserts) |
| Support in languages | Universal (stdlib in Python, Java, .NET, Node 14.17+) | Growing (stdlib in Python 3.13+, uuid npm 10+, google/uuid 1.6+) |
| Looks like | f47ac10b-58cc-4372-a567-0e02b2c3d479 | 0190c0a7-73b7-7000-b7c8-4b4aabd7e00e |
The Database Performance Difference
This is the only practical reason to choose between v4 and v7. When UUID v4 is used as a database primary key, each insert goes to a random position in the B-tree index. At scale this causes:
- Frequent page splits as rows must be inserted mid-page
- High index fragmentation — filled pages can't accept new rows
- Increased I/O as old pages are read into cache for every insert
UUID v7 timestamps its first 48 bits with a millisecond Unix timestamp. New rows always append near the end of the index, just like an auto-increment integer. The benefit is particularly pronounced in PostgreSQL and MySQL at tables over a few million rows.
Decision Guide
Use UUID v7 Recommended
- New project with a relational database
- High-write tables (orders, events, logs)
- You want rows naturally sorted by creation time
- Distributed system — no central ID sequence
Use UUID v4
- Existing system already using v4 (no urgent reason to switch)
- The UUID must not reveal creation time
- You need maximum randomness (122 vs 74 bits)
- IDs used outside a database (tokens, keys, correlation IDs)
Try Both Generators
Generate UUID v4 or v7 in your browser — no signup, nothing sent to servers.
Frequently Asked Questions
Should I use UUID v4 or v7 for database primary keys?
For new projects, prefer UUID v7. It encodes a millisecond timestamp in the first 48 bits, so rows insert in roughly sequential order in B-tree indexes — avoiding costly page splits and index fragmentation. UUID v4 inserts at random positions and causes fragmentation at scale. If you already have a system running v4, there's no urgent reason to migrate unless index performance is a documented problem.
Is UUID v7 globally unique like v4?
Yes. UUID v7 has 74 bits of randomness (versus 122 in v4) which still makes collisions astronomically unlikely for any real-world application. The remaining bits encode a millisecond timestamp plus version/variant markers. It is safe to use as a globally unique identifier.
Does UUID v7 leak timing information?
Yes, to a degree. UUID v7 encodes a millisecond Unix timestamp in the first 48 bits, so anyone who sees the UUID can extract approximately when it was created. For most applications this is fine — creation time is not sensitive. If you must conceal creation time (e.g. opaque session tokens exposed to users), use UUID v4.
How do I migrate from UUID v4 to v7 in an existing database?
You don't need to migrate existing rows — old v4 IDs remain valid. For new rows, change the UUID generation call to produce v7 (e.g. uuid.uuid7() in Python 3.13+, uuid.NewV7() in Go's google/uuid). The columns remain the same type. The main consideration is any code that sorts by UUID string — v4 and v7 won't sort consistently with each other, which matters if mixed-version sorting is required.