UUIDs Explained: Versions, Uniqueness, and When to Use Them

A UUID (Universally Unique Identifier), also called a GUID, is a 128-bit value used to label something uniquely without a central authority handing out numbers. Two machines on opposite sides of the planet, with no network connection between them, can each mint a UUID and trust that the two values will not collide. That property — decentralized uniqueness — is what makes UUIDs so useful in distributed systems.

Anatomy of a UUID

A UUID is usually written as 32 hexadecimal digits in five hyphen-separated groups: 8-4-4-4-12, for example 550e8400-e29b-41d4-a716-446655440000. Within those 128 bits, a few bits are reserved to encode the version (how the UUID was generated) and the variant (the layout standard). The remaining bits carry the actual identifying data.

The Versions That Matter

• Version 4 (random): almost all bits are random. Simple, dependency-free, and the most common choice. The downside is that values are unordered, which hurts database index locality.
• Version 7 (time-ordered): the high bits are a Unix millisecond timestamp followed by random bits. Values generated later sort after earlier ones, giving you decentralized uniqueness AND good index performance. v7 is the modern recommended default for database keys.
• Version 1 (timestamp + MAC address): time-based but historically leaked the generating machine's MAC address and clock. Largely superseded by v7.
• Versions 3 and 5 (name-based): deterministic UUIDs derived by hashing a namespace plus a name (MD5 for v3, SHA-1 for v5). The same input always yields the same UUID — useful for stable IDs derived from existing data.

How Unique Is 'Universally Unique'?

A version 4 UUID has 122 random bits, giving roughly 5.3 × 10^36 possible values. By the birthday paradox, you would need to generate about one billion UUIDs per second for around 85 years to reach a 50% chance of a single collision. In practical terms, collisions do not happen — provided your random number generator is cryptographically sound. The real-world risk is not the math but a broken or poorly seeded RNG producing predictable values.

UUIDs vs Auto-Increment IDs

Sequential integer keys (1, 2, 3...) are compact, fast to index, and human-friendly, but they require a single authority to assign them and they leak information: an order ID of 8000 tells a competitor roughly how many orders you have, and lets anyone enumerate your records by counting up. UUIDs avoid both problems. They can be generated on the client before a database round-trip, they reveal no count, and they let you merge data from multiple sources without key conflicts.

The trade-offs: UUIDs are 16 bytes versus 4 or 8 for integers, they are unwieldy in URLs and support tickets, and random v4 values scatter writes across a B-tree index, fragmenting it. Version 7 fixes the index-locality problem by being time-ordered, which is why it is the preferred form when UUIDs are used as primary keys.