UUID v4 vs v7 — Which UUID Version Should You Use? | LangStop Blog
UUID v4 vs v7 — Which UUID Version Should You Use?
Universally Unique Identifiers (UUIDs) are everywhere in modern software: database primary keys, distributed system identifiers, session tokens, and API resource identifiers. But not all UUIDs are created equal.
With the introduction of UUID v7 (time-ordered UUIDs), developers now have a compelling alternative to the ubiquitous UUID v4 (random UUIDs). This guide compares both versions to help you decide which one belongs in your next project.
Tip: Generate UUID v4 or v7 instantly using the UUID Generator. Fully client-side—no server requests, complete privacy.
What Are UUIDs?
A UUID is a 128-bit identifier standardized by RFC 4122 (and its update, RFC 9562). The canonical textual representation looks like:
550e8400-e29b-41d4-a716-446655440000
UUIDs are designed to be unique across space and time without requiring a central authority. There are several versions, each using a different strategy to generate the 128 bits.
UUID v4: Random UUIDs
UUID v4 generates identifiers using random or pseudo-random numbers. Of the 128 bits, 122 are randomly generated (6 bits are reserved for version and variant markers).
How UUID v4 Works
Version 4 UUID Structure:
xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
Where:
- x = random hex digit (62 bits of randomness)
- 4 = version indicator (4 bits)
- y = variant (2 bits, one of 8, 9, a, or b)
- Remaining = random hex digits
Example UUID v4
f47ac10b-58cc-4372-a567-0e02b2c3d479
Pros of UUID v4
- Maximum randomness — 122 random bits means ~5.3 × 10³⁶ possible values
- No coordination needed — Any system can generate IDs independently
- Simple implementation — Just need a CSPRNG (cryptographically secure PRNG)
- No monotonicity concerns — Security-relevant IDs can't be predicted
Cons of UUID v4
- Random B-tree index fragmentation — Random inserts cause page splits in database indexes
- Poor data locality — Related rows aren't stored together
- No inherent sorting — Can't sort by creation time
- Cache miss rate — Higher in clustered indexes
UUID v7: Time-Ordered UUIDs
UUID v7 (defined in RFC 9562) generates identifiers with a time-ordered prefix, followed by random bits. This makes them sortable by creation time while maintaining uniqueness.
How UUID v7 Works
Version 7 UUID Structure:
tttttttt-tttt-7xxx-yxxx-xxxxxxxxxxxx
Where:
- t = Unix timestamp in milliseconds (48 bits)
- 7 = version indicator (4 bits)
- x = random/sequential sub-millisecond bits
- y = variant (2 bits)
- Remaining = random bits (62-74 bits of randomness)
Example UUID v7
018f3b6a-7e4c-7a3c-b123-2c3d479e0a1b
Pros of UUID v7
- Monotonically increasing — New UUIDs are always "greater" than old ones
- B-tree friendly — Sequential inserts reduce page splits
- Sortable by time — Can order by UUID alone
- Good data locality — Related time-range data stored together
- Still unique — 62+ random bits provide collision resistance
- Timestamp embedded — No separate
created_atcolumn needed
Cons of UUID v7
- Time dependency — Requires accurate clock (but sub-millisecond random component handles clock issues)
- Slightly less randomness — Fewer random bits than v4
- Newer standard — Not all libraries support it yet (but adoption is growing fast)
- Predictable ordering — If you need truly unpredictable IDs, use v4
Database Index Performance: The Key Difference
The most important practical difference between UUID v4 and v7 is database index performance.
B-Tree Index Structure
Relational databases use B-tree indexes for primary keys. When inserting random values:
UUID v4 (Random):
- New IDs land anywhere in the tree
- Causes frequent page splits (50-100% overhead)
- Index fragmentation increases over time
- Cache hit rate decreases
UUID v7 (Time-ordered):
- New IDs are always appended at the end
- Page splits are rare
- Index stays compact and efficient
- Excellent cache locality
Performance Impact
| Metric | UUID v4 | UUID v7 | Improvement |
|---|---|---|---|
| Insert rate (sequential) | ~25K ops/s | ~45K ops/s | ~80% faster |
| Page splits per 1M rows | ~200,000 | ~200 | ~99.9% fewer |
| Index size after 10M rows | ~450 MB | ~320 MB | ~30% smaller |
| Cache miss rate | ~15% | ~2% | ~87% fewer |
| SELECT by ID range scan | Inefficient | Efficient | — |
Data sourced from benchmarks on PostgreSQL 16 with default B-tree settings.
When to Use UUID v4
Security-Sensitive Use Cases
- Session tokens — Should be unpredictable
- Password reset tokens — Must be unguessable
- API keys — Need cryptographic randomness
- Temporary identifiers — Where timing shouldn't leak information
Non-Database Use Cases
- Client-generated correlation IDs
- Distributed tracing spans
- Message queue identifiers
When You Need No Coordination
- Offline systems generating IDs independently
- Event sourcing where any node produces IDs
When to Use UUID v7
Database Primary Keys
- PostgreSQL — Primary key with B-tree index
- MySQL / MariaDB — Clustered primary key
- SQLite — Rowid alias
Time-Sorted Data
- Event logs — Where temporal ordering is useful
- Audit trails — Sort by ID to get chronological order
- Time-series data — Partitioned by time range
Large-Scale Systems
- High-write-volume tables — Reduce index contention
- Multi-region databases — Distributed but sortable
- CQRS/Event Sourcing — Event ordering without timestamps
Ecosystem Support
| Database | UUID v4 | UUID v7 |
|---|---|---|
| PostgreSQL | ✅ Built-in (gen_random_uuid()) |
✅ With pg_uuidv7 extension or gen_uuid_v7() |
| MySQL 8+ | ✅ Built-in | ✅ Built-in UUID_TO_BIN() |
| SQLite | ✅ | ✅ With extension |
| CockroachDB | ✅ | ✅ Built-in gen_random_uuid() |
Programming Language Support
| Language | UUID v4 | UUID v7 |
|---|---|---|
| JavaScript | ✅ crypto.randomUUID() |
✅ crypto.randomUUID({ version: 7 }) |
| Python | ✅ uuid.uuid4() |
✅ uuid.uuid7() (Python 3.14+) |
| Go | ✅ google/uuid |
✅ google/uuid v1.6+ |
| Rust | ✅ uuid::Uuid::new_v4() |
✅ uuid::Uuid::new_v7() |
| Java | ✅ UUID.randomUUID() |
✅ Custom implementation |
Recommendation
| Scenario | Recommended UUID Version |
|---|---|
| Database primary key (high write volume) | v7 |
| Database primary key (low write volume) | Either |
| Security token / API key | v4 |
| Distributed event sourcing | v7 |
| Client-generated identifiers | v4 (simpler, well-supported) |
| Time-sorted data | v7 |
| Session identifier | v4 |
| Cross-system reference ID | Either (agree on version) |
The trend: For database primary keys, UUID v7 is rapidly becoming the default choice. PostgreSQL's pg_uuidv7 extension, MySQL's built-in support, and growing library support make it production-ready today.
Generating UUIDs Online
Use LangStop's free UUID generators — both run 100% client-side with no server uploads:
- UUID v4 Generator — Generate random UUIDs
- UUID v7 Generator — Generate time-ordered UUIDs
Need UUIDs?
Generate any UUID version with LangStop's free tool:
Client-side generation. No tracking. No limits.