UUID (Universally Unique Identifier, RFC 9562) is a 128-bit value formatted as 32 hexadecimal characters with dashes (550e8400-e29b-41d4-a716-446655440000). Multiple versions define different generation strategies, but all target the same goal: an ID you can generate anywhere with negligible collision probability.
Common Versions
| Version | Basis | Sortable? | Recommended for |
|---|---|---|---|
| v1 | Timestamp + MAC address | Sort of | Legacy |
| v3 | MD5 hash of name + namespace | ❌ | Namespaced IDs |
| v4 | Random | ❌ | General-purpose (still common) |
| v5 | SHA-1 hash of name + namespace | ❌ | Namespaced IDs |
| v6 | Reordered v1 for lexical sort | ✅ | Migration from v1 |
| v7 | Unix timestamp (ms) + random | ✅ | Modern default — DB primary keys |
Why v7 Is the Modern Choice
- Sortable — inserts are append-mostly on B-tree indexes, avoiding random-write hotspots
- Timestamp is directly readable — useful for debugging
- Still 122 bits of randomness — collision probability vanishing
Collision Probability
For UUIDv4, the birthday-paradox math: you’d need to generate roughly 2.7 × 10^18 UUIDs before there’s a 50% chance of a single collision. In practice this means: never worry about UUIDv4 collisions.
UUID as Primary Key
Trade-off with sequential integers:
- ✅ Generated client-side, no coordination
- ✅ Non-guessable IDs (URL security)
- ❌ Larger (16 bytes vs 4-8)
- ❌ v4 causes index fragmentation — use v7
Generate v4, v7, and other UUIDs with the UUID generator.
Related
Check the JWT glossary entry, the SHA-256 entry, and read the UUID v4 vs v7 FAQ.