UUIDs are everywhere: databases, distributed systems, session tokens, everywhere you need guaranteed uniqueness without central coordination. But what exactly is a UUID, and when should you use one?
What Is a UUID?
A UUID is a 128-bit identifier, typically represented as a 36-character string: "550e8400-e29b-41d4-a716-446655440000". There are several versions, but UUIDv4 is most common—randomly generated and practically guaranteed to be unique.
The math: 2^128 possible UUIDs. That's about 340 undecillion (3.4 × 10^38). Even if you generated a trillion UUIDs per second, it would take longer than the universe has existed to have a 50% chance of a collision.
When to Use UUIDs
Distributed systems: Multiple services generating IDs independently can't step on each other's toes if they all use UUIDs. No central ID server needed.
Public identifiers: Don't expose sequential database IDs (1, 2, 3...) in URLs. UUIDs don't reveal how many records you have or the order they were created.
Merging datasets: Two databases can have overlapping IDs. UUIDs from different sources won't collide.
When NOT to Use UUIDs
Primary keys in high-write databases: UUIDs are random, causing index fragmentation. Sequential IDs (like auto-increment) are better for write performance.
URL parameters: UUIDs are long and ugly. Use them if you need true uniqueness, but for public-facing URLs, consider shorter slugs instead.
Sorting: UUIDs have no natural order. If you need insertion order, use sequential IDs or add a created_at timestamp.