UUIDs: The Unique IDs That Power Everything

A Database Merger Horror Story (That Could've Been Prevented)

Okay so picture this. It's November 2020—peak pandemic chaos—and my team is merging two user databases from an acquisition. Both systems used auto-increment integer IDs. User 1 from Company A is obviously not User 1 from Company B.

The "solution"? Add a million to all the IDs from one database. Should work, right? We had maybe 50,000 users. Plenty of buffer.

Except someone forgot about foreign keys in three tables. Orders started linking to wrong customers. Support tickets attached to accounts that didn't file them. One very confused user got an email thanking them for a $47,000 purchase they definitely didn't make.

We spent three days untangling that mess. Three. Days. Of mapping broken relationships, running migration scripts, and apologizing to very confused customers.

If both systems had used UUIDs from the start? None of this happens. The IDs would've been unique across both databases. No collision possible.

That's the sales pitch for UUIDs. Let me explain what they actually are.

What's a UUID Anyway?

Universally Unique Identifier. 128 bits of data formatted like this:

550e8400-e29b-41d4-a716-446655440000

Thirty-two hex characters, five groups, four hyphens. Looks intimidating but it's just a really big number in disguise.

The magic? You can generate one anywhere—your server, my laptop, someone's phone in rural Montana—and it'll be unique. No coordination needed. No central authority to check with. No database round-trip to get the next number.

How unique? There are about 340 undecillion possible v4 UUIDs. That's 340 followed by 36 zeros. You'd need to generate a billion per second for 85 years to have a 50% chance of one collision. I think we're good.

Wait, There Are Different Versions?

Yeah, this threw me off too. UUID has versions and they're not all created equal.

Version 1 uses your computer's MAC address plus a timestamp. Guaranteed unique but—here's the fun part—it leaks when and where it was generated. Probably don't use this unless you want people knowing your network card's fingerprint.

Version 4 is random. 122 bits of randomness (6 bits are used for version info). This is what most people mean when they say "UUID." It's what you probably want.

Version 5 is a hash of a namespace plus a name. Same inputs always produce the same output. Useful when you need deterministic IDs from strings—like generating a UUID from a URL.

Version 7 is the new hotness. Timestamp-based but sorted chronologically, which makes database indexes happier. If you're starting a new project in 2024+, worth considering.

For 95% of use cases? Just use v4. Random is fine.

When UUIDs Make Sense (And When They Don't)

Good ideas:

Generate IDs before database insert. You can start using the ID in your UI immediately—no waiting for the database to tell you what number you got. Great for optimistic updates.

Distributed systems. Multiple servers generating IDs without talking to each other? UUIDs handle this beautifully.

Public URLs. /users/123 tells attackers you have at least 123 users and they can probably scrape sequential IDs. /users/550e8400-e29b-41d4-a716-446655440000 tells them nothing.

Bad ideas:

Human-readable references. Order numbers, invoice IDs, ticket numbers—anything humans need to read aloud or type manually. "My order number is five-five-zero-e-eight-four..." Nobody wants that.

Storage-constrained systems. 16 bytes vs 4 bytes for a 32-bit int. Usually doesn't matter, but at massive scale in something like IoT with millions of devices, it adds up.

The Tool

UUID Generator — click button, get UUID. I use this constantly when seeding test data or mocking API responses. v4 by default because that's what you probably need.

UUID vs GUID: Same Thing, Different Name

Microsoft calls them GUIDs (Globally Unique Identifier). Everyone else calls them UUIDs. Format is identical. APIs might use either term. Don't let it confuse you—it's just branding.

Storage Gotchas

PostgreSQL has a native uuid type. Use it. MySQL... doesn't really. You'll store them as CHAR(36) for readable or BINARY(16) for efficient. I usually go CHAR because debugging is easier when you can actually read the IDs in your database client.

Always store lowercase. Technically UUIDs are case-insensitive, but if you mix cases, string comparisons will fail and you'll spend an afternoon figuring out why WHERE id = ? returns nothing.

Generate a UUID and stop using auto-increment for things that might ever need to be merged.