UUID Guide: Versions, Formats and When to Use Each
Quick Answer
- *A UUID is a 128-bit identifier formatted as 32 hex digits in 8-4-4-4-12 pattern (36 characters total).
- *UUID v4 (random) is the most widely used. UUID v7 (time-sorted) is the modern recommendation for databases.
- *Collision probability is astronomically low — you'd need 2.71 quintillion v4 UUIDs for a 50% chance of one duplicate.
- *Random UUIDs fragment B-tree indexes. Time-sorted versions (v1, v6, v7) solve this for database primary keys.
What Is a UUID?
A Universally Unique Identifier (UUID) is a 128-bit label used to identify information in computer systems without requiring a central coordinating authority. The standard was originally published as RFC 4122 in 2005 and updated by RFC 9562 in May 2024, which introduced versions 6, 7, and 8.
UUIDs are formatted as 32 hexadecimal characters separated by hyphens: 550e8400-e29b-41d4-a716-446655440000. The 13th character indicates the version, and the 17th character indicates the variant (typically starting with 8, 9, a, or b for RFC 4122/9562 UUIDs).
UUID Versions Compared
RFC 9562 defines eight UUID versions. Here are the ones developers actually encounter:
| Version | Source | Sortable | Random Bits | Status |
|---|---|---|---|---|
| v1 | Timestamp + MAC address | Yes (with byte reorder) | 0 | Legacy |
| v3 | MD5 hash of namespace + name | No | 0 | Legacy |
| v4 | Random / pseudo-random | No | 122 | Widely used |
| v5 | SHA-1 hash of namespace + name | No | 0 | Active |
| v6 | Reordered v1 timestamp | Yes | 0 | New (RFC 9562) |
| v7 | Unix timestamp + random | Yes | 74 | Recommended |
UUID v4: The Random Standard
UUID v4 generates 122 random bits (6 bits are reserved for version and variant). It is the most commonly used version. According to npm download statistics, the uuid package generates over 180 million downloads per week as of early 2026, with v4 being the default.
The collision probability follows the birthday paradox. For 122 random bits, you need approximately 2.71 × 10¹⁸ UUIDs for a 50% collision probability. If you generated 1 billion UUIDs per second, it would take roughly 85 years to reach that threshold. For practical purposes, v4 collisions do not happen.
UUID v7: The Modern Choice
UUID v7, introduced in RFC 9562, embeds a 48-bit Unix timestamp (millisecond precision) in the most significant bits, followed by 74 bits of randomness. This makes v7 UUIDs monotonically increasing over time while retaining strong uniqueness guarantees.
The key advantage is database performance. According to Percona's 2024 benchmarks, using UUID v7 as a primary key in PostgreSQL delivers insert throughput within 5% of sequential integers, compared to a 20–40% penalty with random UUID v4. The time-ordered prefix keeps B-tree index pages filled sequentially, reducing page splits and fragmentation.
UUIDs vs Auto-Increment IDs
| Factor | Auto-Increment | UUID v4 | UUID v7 |
|---|---|---|---|
| Size | 4–8 bytes | 16 bytes | 16 bytes |
| Index performance | Excellent | Poor (fragmentation) | Good (sequential) |
| Distributed generation | Requires coordination | No coordination | No coordination |
| Predictability | Sequential (guessable) | Random | Time-prefixed |
| URL safety | Enumerable | Not enumerable | Not easily enumerable |
According to a 2025 survey by PlanetScale, 62% of new applications use UUIDs as primary keys, up from 41% in 2021. The shift toward microservices and distributed systems has made coordination-free ID generation a practical necessity.
UUID Storage and Performance Tips
Store as BINARY(16), Not VARCHAR(36)
Storing UUIDs as their 16-byte binary representation instead of a 36-character string saves 56% storage space and improves index performance. PostgreSQL's native uuid type handles this automatically. MySQL users should use BINARY(16) with UUID_TO_BIN().
Use UUID v7 for Primary Keys
If your primary key is a UUID, always prefer v7 over v4. The monotonic ordering prevents B-tree fragmentation. In PostgreSQL, the pg_uuidv7 extension generates these natively.
Consider ULID as an Alternative
ULIDs (Universally Unique Lexicographically Sortable Identifiers) encode a 48-bit timestamp and 80 random bits in a 26-character Crockford Base32 string. They serve a similar purpose to UUID v7 but in a more compact text representation. According to GitHub topic statistics, ULID repositories have over 15,000 stars collectively across implementations.
Generate UUIDs instantly
Use our free UUID Generator →Frequently Asked Questions
What is the probability of a UUID collision?
For UUID v4, which uses 122 random bits, you would need to generate approximately 2.71 quintillion (2.71 × 10¹⁸) UUIDs to have a 50% chance of a single collision. Generating 1 billion UUIDs per second, it would take about 85 years to reach that point.
Which UUID version should I use?
For most applications in 2026, UUID v7 is the best choice. It is time-sortable, uses a Unix timestamp prefix for efficient database indexing, and fills the remaining bits with randomness. If your platform does not support v7 yet, UUID v4 (fully random) remains the safe default.
Are UUIDs slower than auto-increment IDs for database indexing?
Random UUIDs (v4) cause B-tree index fragmentation because new values scatter across the index. This can reduce insert performance by 20–40% compared to sequential IDs in PostgreSQL benchmarks. Time-sorted UUIDs (v7) largely eliminate this problem because their values increase monotonically.
How many characters is a UUID?
A standard UUID is 36 characters long in its canonical string form: 32 hexadecimal digits separated by 4 hyphens in the pattern 8-4-4-4-12. As raw bytes, a UUID is 128 bits or 16 bytes.
Can I extract the timestamp from a UUID?
Yes, but only from time-based versions. UUID v1 embeds a 60-bit timestamp with 100-nanosecond resolution starting from October 15, 1582. UUID v7 embeds a 48-bit Unix timestamp in milliseconds. UUID v4 contains no timestamp since it is entirely random.