UUID Guide: Versions, Formats & When to Use Each

What Is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit label used to identify resources without requiring a central authority. The standard format looks like this: 550e8400-e29b-41d4-a716-446655440000 — 32 hexadecimal characters separated by four hyphens into five groups (8-4-4-4-12).

UUIDs solve a fundamental distributed systems problem: how do you generate a unique identifier on two different machines at the same time without them talking to each other? With UUIDs, the probability of collision is so low that you can treat them as unique for practical purposes.

The formal specification is RFC 4122 (with RFC 9562 updating it in 2024 to add v6, v7, and v8). Most programming languages include UUID generation in their standard library or have a widely-used package for it.

UUID Versions Explained

UUID v1 — Timestamp + MAC Address

Version 1 combines a 60-bit timestamp (100-nanosecond intervals since October 15, 1582) with the machine's MAC address. This guarantees uniqueness across time and space but leaks the generating machine's identity and the exact time of creation. It is rarely recommended today for new projects due to the privacy concern.

UUID v4 — Random

Version 4 is the most widely used. It generates 122 random bits (6 bits are fixed for version and variant markers). With a good random source, collisions are essentially impossible — you would need to generate 2.71 quintillion UUIDs to have a 50% chance of a single collision.

The downside: v4 UUIDs are completely random, which causes poor performance as database primary keys in B-tree indexes because inserts are scattered across the tree.

UUID v7 — Timestamp-Ordered Random

Version 7 (RFC 9562, 2024) is the new recommended version for most use cases. It embeds a Unix timestamp in milliseconds in the first 48 bits, followed by random data. This means v7 UUIDs are sortable by creation time and insert sequentially into database indexes — solving v4's performance problem while maintaining randomness for uniqueness.

Other Versions

Version 3 (MD5 hash of namespace + name) and Version 5 (SHA-1 hash) are deterministic — the same input always produces the same UUID. Useful when you need a stable identifier derived from a known value. Version 6 is a reordered v1 for better sortability but v7 is generally preferred over v6.

UUID vs Auto-Increment

Auto-incrementing integers (1, 2, 3...) are simpler, smaller (4 or 8 bytes vs 16 bytes), and produce perfectly ordered inserts. So why use UUIDs at all?

• Distributed generation: Multiple services or databases can create IDs without coordination. Auto-increment requires a single authority.
• Merge-friendly: When combining data from multiple sources, UUIDs do not collide. Integer IDs from different systems will.
• Security: Sequential IDs expose record counts and are easy to enumerate. UUIDs are not guessable.
• Client-side generation: You can generate the ID before the database insert, which simplifies optimistic UI patterns and offline-first apps.

For single-database applications with no enumeration concerns, auto-increment is simpler. For anything distributed, multi-tenant, or API-facing, UUIDs (especially v7) are the better choice.

Database Performance

Random UUIDs (v4) cause fragmented B-tree indexes. Every insert lands in a random position, splitting pages and creating a larger, less cache-friendly index. On large tables (millions of rows), this can degrade insert performance by 2-5x compared to sequential keys.

Solutions:

• Use UUID v7: The timestamp prefix ensures new UUIDs are always greater than previous ones, producing sequential inserts just like auto-increment.
• Store as binary(16): Storing UUIDs as their raw 16-byte binary form instead of a 36-character string reduces index size by more than half. PostgreSQL's uuid type does this automatically. In MySQL, use BINARY(16) with UUID_TO_BIN().
• Use ULID or KSUID: These are UUID alternatives designed specifically for ordered generation and compact encoding. ULID is particularly popular in JavaScript ecosystems.

Collision Probability

For UUID v4 with 122 random bits, the math is straightforward. After generating n UUIDs, the collision probability approximates n^2 / (2 * 2^122). In practical terms:

• 1 billion UUIDs: collision probability is about 1 in 10^20 (one hundred quintillion). Negligible.
• The entire world generating 1 billion UUIDs per second for 85 years would reach a 50% collision chance.

The real risk is not mathematical collision — it is a broken random number generator. Always use a cryptographically secure random source (crypto.randomUUID() in browsers, crypto.randomBytes() in Node.js, /dev/urandom on Linux).

Generate UUIDs Instantly

Need UUIDs right now? Our UUID Generator creates v4 and v7 UUIDs in your browser. Generate single IDs or bulk batches, copy with one click, and use them in your code, database seeds, or API testing. No data leaves your device.