UUID Versions Explained
A complete guide to UUID versions 1 through 7. Understand the trade-offs and choose the right version for your application.
✅ Quick Recommendation
General use: Use UUID v4 (random). Simple, widely supported, good for most APIs.
Database primary keys: Use UUID v7 (time-sorted). Much better index performance.
Deterministic IDs: Use UUID v5 (namespace). Same input always produces same UUID.
UUID Format (128 bits)
The "4" in position 13 indicates version (v4). The "a" in position 17 indicates variant (RFC 4122).
All UUID Versions
UUID v1: Time-based
Timestamp + MAC address
- • Sortable by time (roughly)
- • No collision risk
- • Can extract timestamp
- • Exposes MAC address (privacy)
- • Sequential = guessable
- • Clock sync issues
Best for: Legacy systems, audit logs
UUID v2: DCE Security
Timestamp + local domain ID
- • POSIX-compliant
- • Domain-scoped
- • Rarely used
- • Complex implementation
- • Poor documentation
Best for: DCE/POSIX environments only
UUID v3: Namespace (MD5)
MD5 hash of namespace + name
- • Deterministic (same input = same UUID)
- • No external dependencies
- • MD5 is cryptographically weak
- • Prefer v5 for new projects
Best for: Deterministic IDs from names
UUID v4: Random
122 random bits
- • Simple
- • No privacy concerns
- • Unpredictable
- • Most libraries support
- • Not sortable
- • Poor database index performance
- • Theoretical collision risk
Best for: General purpose, APIs, tokens
UUID v5: Namespace (SHA-1)
SHA-1 hash of namespace + name
- • Deterministic
- • Stronger than v3
- • Same input = same UUID
- • SHA-1 deprecated for security
- • Still fine for UUID generation
Best for: Deterministic IDs, URL-to-UUID
UUID v6: Reordered Time
v1 bits reordered for sorting
- • Time-sortable (lexicographically)
- • Compatible with v1 systems
- • Still exposes MAC
- • Less adopted than v7
Best for: Drop-in v1 replacement needing sort
UUID v7: Unix Time + Random
48-bit Unix timestamp ms + 74 random bits
- • Time-sortable
- • No MAC exposure
- • DB index friendly
- • Future standard
- • Newer, less library support
- • Draft RFC (as of 2024)
Best for: New projects, databases, distributed systems
Quick Comparison
| Version | Sortable? | Deterministic? | Privacy Safe? | DB Perf? |
|---|---|---|---|---|
| v1 | ~Time | No | ❌ MAC exposed | Medium |
| v4 | Random | No | ✅ Random | Poor |
| v5 | Hash-based | ✅ Yes | ✅ Safe | Medium |
| v7 | ✅ Time | No | ✅ Safe | ✅ Excellent |
Database Performance
Index Performance
v4 UUIDs cause random inserts, fragmenting B-tree indexes. v7 UUIDs insert sequentially, improving performance 10-100x.
💡 Use v7 for primary keys in high-write databases
Storage Size
All UUIDs are 128 bits (16 bytes). Store as BINARY(16) or native UUID type, not VARCHAR(36).
💡 Save 56% space using binary storage
Collision Risk
With 122 random bits (v4), 2.71×10^18 UUIDs needed for 50% collision probability. In practice: virtually impossible.
💡 Don't worry about collisions in v4/v7