UUID v4 vs v7: Which Should You Use in 2026?
UUID v4 vs UUID v7 compared: random vs time-sorted, database indexing, PostgreSQL and MySQL performance, and when to use which version.
UUID v4 vs UUID v7: A Practical Comparison
UUID v4 and UUID v7 are both excellent choices for generating unique identifiers, but they serve different purposes. UUID v4 is fully random and has been the default choice for over 15 years. UUID v7, standardized in RFC 9562 (May 2024), embeds a Unix timestamp in the first 48 bits, making UUIDs naturally time-ordered while keeping the remaining 74 bits random. This seemingly small change has major implications for database performance.
Structure Comparison
UUID v4: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
|<------- 122 random bits -------->|
(4 = version, y = variant)
UUID v7: tttttttt-tttt-7rrr-yrrr-rrrrrrrrrrrr
|<-48bit->| |<-- 74 random bits-->|
timestamp ver variant + randomDatabase Indexing Performance
This is the primary reason UUID v7 exists. B-tree indexes (used by every major database) perform best when new values are appended sequentially. UUID v4's random distribution causes:
- Page splits — new UUIDs insert at random positions in the index, forcing existing pages to split. This fragments the index over time.
- Cache misses — random UUIDs touch random index pages, defeating the database buffer pool. A hot table with UUID v4 PKs can require 5-10x more RAM for the same query performance.
- Write amplification — fragmented indexes require more disk I/O for the same number of writes.
UUID v7 solves all three problems because new UUIDs are always larger than previous ones (within the same millisecond, the random suffix provides ordering). Inserts always go to the end of the index, just like auto-increment integers.
Benchmark Results
| Metric | UUID v4 | UUID v7 | Auto-increment |
|---|---|---|---|
| INSERT speed (1M rows) | Baseline | ~2-3x faster | ~3-4x faster |
| Index size (1M rows) | ~20% larger (fragmented) | Compact | Compact |
| SELECT by PK | Similar | Similar | Similar |
| Range queries (recent) | Full scan needed | Sequential scan | Sequential scan |
When to Use UUID v4
- Security-sensitive IDs — v4 reveals no information about creation time or ordering. Use for API tokens, session IDs, and any user-facing identifier where you do not want to leak metadata.
- Non-database use cases — correlation IDs, temporary identifiers, idempotency keys, and file names where index performance is irrelevant.
- Legacy compatibility — existing systems that validate UUID format may reject v7 UUIDs (version digit = 7 instead of 4).
When to Use UUID v7
- Database primary keys — any table where insert performance and index efficiency matter.
- Event sourcing — event IDs that are naturally time-ordered simplify replay and debugging.
- Distributed systems — generate IDs across multiple services without coordination, while maintaining rough chronological order.
- Audit logs — time-sortable IDs eliminate the need for a separate timestamp column in many cases.
The Verdict for 2026
Use UUID v7 as your default for new projects, especially for database primary keys. Use UUID v4 when you specifically need unpredictability (security tokens, external-facing IDs) or when working with systems that do not yet support v7. If your language or framework does not have v7 support yet, UUID v4 with a separate created_at timestamp column remains a solid approach.