UUID v4 vs v7 — Which Should You Use?
UUID v7 is the modern replacement for v4 in databases. Unlike v4's pure randomness, v7 embeds a millisecond Unix timestamp making identifiers time-sortable. Learn when to use UUID v4 vs v7 and why ordered UUIDs matter for database performance.
The short answer
If you are storing UUIDs in a database as a primary key, use v7. If you need a random, opaque identifier for tokens, session IDs, or anything where timestamp exposure is a concern, use v4.
What is UUID v4?
UUID v4 (defined in RFC 4122, now superseded by RFC 9562) generates 122 bits of cryptographic randomness. The result is completely unpredictable, which is ideal for security tokens but terrible for database indexes.
What is UUID v7?
UUID v7 (defined in RFC 9562, published April 2024) embeds a 48-bit Unix timestamp in milliseconds into the first 12 hex characters. The remaining bits are random. This makes v7 UUIDs monotonically increasing — newer UUIDs are always lexicographically greater than older ones.
Why does ordering matter for databases?
Most databases use a B-tree index for primary keys. When you insert rows with random UUIDs (v4), each insert lands at a random position in the index — forcing the database to read, split, and rewrite index pages constantly. At scale this causes:
- Index fragmentation — the B-tree becomes unbalanced and sparse
- High I/O — random page reads instead of sequential appends
- Slower inserts — page splits under write load
- Worse cache locality — recent rows are scattered across pages
UUID v7 solves all of this. Because each new ID is larger than the previous one, inserts always append to the right-most leaf of the index — exactly like an auto-incrementing integer, but globally unique.
Comparison table
| Property | UUID v4 | UUID v7 |
|---|---|---|
| RFC standard | RFC 4122 / RFC 9562 | RFC 9562 (2024) |
| Format | 128-bit random | 48-bit timestamp + 80-bit random |
| Sortable | ✗ No | ✓ Yes — chronological order |
| DB index performance | ⚠ Poor (random inserts) | ✓ Excellent (sequential appends) |
| Guessable | ✗ No | ⚠ Timestamp is visible |
| Collision risk | Negligible | Negligible |
| Best for | Tokens, session IDs, file names | Database primary keys, event IDs |
When to stick with v4
- API tokens or bearer tokens where exposing creation time is a privacy concern
- File names or URLs that must be opaque
- Any context where the timestamp embedded in v7 could leak information
- Systems that have not yet adopted RFC 9562 libraries
Database support in 2025
UUID v7 is supported natively or via extension in PostgreSQL (pgcrypto / uuid-ossp discussions), MySQL 8+, and most modern ORMs including Prisma, Drizzle, and Hibernate. Most languages have RFC 9562 libraries available — the format is a drop-in replacement anywhere v4 is accepted.
Related guides
Generate UUID v4 and v7 instantly
Open UUID Generator →