What is a UUID, and when should you use one?

You have probably seen a string like f47ac10b-58cc-4372-a567-0e02b2c3d479 in a URL, a database row, or a config file and wondered what it is and why it is so long. That is a UUID. Its whole job is to be an identifier that any machine can generate on its own, with no shared counter and almost no chance of clashing with anyone else’s. Once you know how it works, you know exactly when to use one and when a plain number is the better tool.

TL;DR: A UUID is a 128-bit identifier, usually shown as 32 hex digits in five groups (8-4-4-4-12). It exists so any machine can mint an ID independently and still avoid collisions, with no central server. Random (version 4) UUIDs stay collision-free until you generate around 2.7 x 10^18 of them. Use one for distributed or client-generated IDs and for public IDs that should not be guessable. Reach for a plain auto-increment integer when a single database owns the keys.

What a UUID actually is

A UUID is a 128-bit value. To make those bits readable, they are written as 32 hexadecimal digits grouped 8-4-4-4-12 and joined by hyphens, like 550e8400-e29b-41d4-a716-446655440000. The hyphens carry no meaning. They just break up the run of digits so your eye can land somewhere. The full name is universally unique identifier, defined in RFC 9562, and GUID, the term you see in Microsoft tools, is the same thing under a different label.

The point of all those bits is range. With 128 bits there are about 3.4 x 10^38 possible values. That is a number large enough that picking one at random and ever picking the exact same one again is, for any workload you will actually run, not going to happen. That huge space is what backs the central promise: an ID generated on one machine will not collide with one generated on another, even though the two never talked to each other.

Why UUIDs exist at all

The problem a UUID solves is generating an identifier with no central authority. A classic database hands out IDs from a single counter: row 1, row 2, row 3, each number issued by one server that remembers what it gave out last. That works fine until you have many servers, offline clients, or systems that must create records before they can reach a database. Two of them both reach for “the next number” and clash.

A UUID skips the counter. Instead of asking a server for the next value, a machine builds a UUID locally from randomness or a timestamp and trusts the value space to keep it unique. No coordination, no round trip, no single place everyone has to ask. A phone in airplane mode can create a record’s ID, a server can create another, and when they sync later the two IDs will not collide. That independence is the entire reason the format exists.

Reading a real UUID

Take f47ac10b-58cc-4372-a567-0e02b2c3d479 and look at two specific spots.

The first digit of the third group is the version. Here it is the 4 in 4372, so this is a version 4 UUID, built mostly from random bits. The first digit of the fourth group is the variant. Here it is the a in a567, which is the common variant used across almost everything you will meet. Those two nibbles are fixed by the spec, which is why they are not free to be random. Everything else in a v4 UUID is random noise.

That is the whole trick to reading one. Third group tells you the version, fourth group tells you the variant, the rest is payload. Generate a few in a UUID generator on dev.hivly.net and watch: the digit in the third group stays fixed at 4, and the rest changes every time.

How unlikely is a collision, really

“Practically impossible” gets repeated a lot without a number attached. Here is the number.

A v4 UUID fixes those version and variant bits, which leaves 122 bits of actual randomness. So there are 2^122 possible v4 UUIDs, about 5.3 x 10^36. But the question that matters is not “how many values exist,” it is “how many do I have to generate before two of them match.” That is the birthday problem, and the answer is much smaller than the total space, because you are looking for any collision among all pairs, not a hit against one specific value.

For a space of size N, the point where a collision passes 50 percent probability sits near the square root of N, times a small constant (about 1.18). The square root of 2^122 is 2^61, roughly 2.3 x 10^18. Times the constant, you get about 2.7 x 10^18 UUIDs, which is 2.7 billion billion, before you would expect even odds of a single duplicate.

Put that on a clock. Generate a billion v4 UUIDs every second, nonstop, and you would need roughly 85 years to reach 2.7 x 10^18 of them, and only then hit 50 percent odds of one collision. Stay well below that scale, which every real system does, and the chance is small enough to ignore. So “universally unique” is not a hard mathematical guarantee, but the gap between the theory and any workload you will run is so wide that production code treats v4 UUIDs as unique and moves on. I have shipped systems minting millions of these and never once written collision-handling code for them, because at that volume there is nothing to handle.

The common versions, and why v7 matters

UUIDs come in several versions, and as you saw above, the first digit of the third group tells you which one you are holding. The two you meet most are version 4 and the time-based versions.

Version 4 is pure randomness inside the fixed layout, so it carries no hint about when or where it was made. That is exactly what makes it a good public ID: you cannot guess the next one from the last one.

Version 1 is the old time-based design, mixing a timestamp with the machine’s network address. That MAC address raised privacy concerns, since an ID could leak which physical machine minted it. Version 7 is the modern time-based option, and it fixes the one real weakness of v4: ordering. A v7 UUID puts a millisecond timestamp at the front, so sorting v7 UUIDs as plain text sorts them by creation time.

That sounds like a small thing until you have watched it hurt a database. Random v4 keys land in random spots across a B-tree index, so a burst of inserts scatters writes all over the index pages and the database keeps rewriting them. v7 keys arrive in time order, so new rows append near the end of the index instead of poking holes throughout it. Same 128-bit format, same collision safety, but the writes stay local and the index stays cheaper to maintain. If you want UUIDs and you are using them as a primary key, v7 is usually the version to pick.

When to use a UUID, and when not to

Reach for a UUID when IDs are born in many places that cannot share a counter: distributed services, multiple databases, or clients that generate keys offline before syncing. Reach for one when you want a public-facing ID that does not expose how many records you have or let someone walk the sequence. A URL ending in /orders/8 invites a quick edit to /orders/9. A URL ending in a UUID gives an attacker nothing to increment.

A plain auto-increment integer is the simpler and often better choice when one database owns all the IDs. Integers are tiny next to a 128-bit value, they index faster, they are easy to read and type, and they sort naturally. The cost of a UUID is real: it takes more space, random versions scatter your index, and nobody reads one aloud without losing their place.

So the choice is not “UUIDs are modern, integers are old.” It is about who creates the IDs and whether the value has to stay opaque. One server owns the keys and they can be sequential? Use an integer. Creation is spread across machines, or the ID must not be guessable? Use a UUID, and prefer v7 when you also want them to sort by time.