UUID vs GUID Explained

They're basically the same thing. But here's the full story.

If you've worked with databases, APIs, or distributed systems, you've seen these 128-bit identifiers everywhere. Some people call them UUIDs, others call them GUIDs. Here's what's actually going on.

UUID and GUID Are the Same Thing (Mostly)

UUID stands for Universally Unique Identifier. GUID stands for Globally Unique Identifier. They refer to the same concept: a 128-bit number formatted as 32 hex digits separated by hyphens. Like this: 550e8400-e29b-41d4-a716-446655440000

UUID is the official name from RFC 4122, the internet standard. GUID is what Microsoft called it when they implemented the same thing in Windows and .NET. If you're in the Microsoft ecosystem, you'll hear GUID. Everywhere else, it's UUID.

The format is identical. A GUID generated in C# and a UUID generated in Python are interchangeable. There are some minor historical differences in byte ordering (Microsoft originally used mixed-endian format), but modern implementations are compatible.

The Versions That Matter

Version 1 (Timestamp) - Combines the current timestamp with the machine's MAC address. This means v1 UUIDs are sortable by creation time and you can theoretically trace them back to the machine that generated them. The privacy implications of embedding a MAC address made this version less popular over time.

Version 4 (Random) - This is the one you'll use 95% of the time. 122 bits of random data (6 bits are used for version and variant info). Generated purely from a cryptographically secure random number generator. No timestamp, no machine info, just randomness.

Version 5 (Namespace) - Generates a deterministic UUID from a namespace and a name using SHA-1. Feed in the same namespace and name, get the same UUID every time. Useful when you need stable identifiers derived from existing data.

Version 7 (Newest) - A newer proposal that puts a Unix timestamp in the first 48 bits, followed by random data. You get the sortability of v1 without the privacy concerns. Database-friendly because sequential inserts perform better on B-tree indexes.

Collision Probability

With Version 4 UUIDs, you get 122 bits of randomness. That's 5.3 x 10^36 possible values. To have a 50% chance of a collision, you'd need to generate about 2.7 x 10^18 UUIDs - that's 2.7 quintillion.

To put that in perspective: if you generated 1 billion UUIDs per second, you'd need to run for about 85 years before having a 50% chance of a single duplicate. You're more likely to be hit by a meteorite. Twice.

In practical terms, UUID collisions don't happen. Your database will hit other limits long before UUID collisions become a concern.

When to Use UUIDs

• Database primary keys - Especially in distributed systems where auto-increment IDs would cause conflicts. UUIDs let any node generate IDs independently.
• Session IDs - Random, unguessable, and unique. Perfect for session tokens.
• API resource identifiers - Exposing sequential IDs in URLs lets users enumerate your data. UUIDs prevent that.
• File names - When you need unique names without coordination between systems.
• Correlation IDs - Trace a request through microservices by attaching a UUID that travels with it.

When NOT to Use UUIDs

• Sequential access patterns - Random UUIDs fragment B-tree indexes. If your primary query is "get the latest 100 records," auto-increment integers or v7 UUIDs perform much better.
• Human-readable IDs - Nobody's going to read "550e8400-e29b-41d4-a716-446655440000" over the phone. For user-facing identifiers, use shorter formats like nanoid or a custom scheme.
• Space-constrained storage - A UUID takes 16 bytes as binary, 36 characters as a string. An integer takes 4-8 bytes. If you're storing billions of rows, this adds up.
• URLs where readability matters - /users/42 is friendlier than /users/550e8400-e29b-41d4-a716-446655440000. Though some teams prefer the security-through-obscurity benefit.

Generate Some