Understanding UUIDs
128 bits of identifier, no coordination needed.
A UUID is the answer to "give me a unique ID without asking a database for one."
The shape.
A UUID — Universally Unique IDentifier — is 128 bits, conventionally written as 32 hex digits split into five groups by hyphens. Total string length is always 36 characters. The format is fixed regardless of which version of UUID you're using.
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Versions — and why v4 dominates.
UUID v1 encodes a timestamp and a MAC address, leaking information about when and where it was created. UUID v3 and v5 hash a name within a namespace — useful when you need a deterministic ID. UUID v4 is purely random — 122 bits of entropy after the version and variant bits are fixed. v4 is the default everywhere because it's unbiased, uncoordinated, and revealing nothing.
Collision odds.
With 122 bits of randomness, the chance of any two UUID v4s colliding is so small that you'd need to generate billions per second for decades to expect a duplicate. In practice, v4 collisions are treated as impossible. If they ever did happen, the cause would be a broken random number generator, not bad luck.
Sortable variants — UUID v7 and v6.
UUID v4's downside is that the values are random, so inserting them as primary keys scatters writes across the B-tree and trashes index locality. UUID v7 (standardised in 2024) puts a millisecond-precision timestamp at the front of the value, so consecutive UUIDs sort monotonically. The result is a UUID that gives you both uniqueness and database-friendly sequential keys — the best of both worlds for new systems.
Where UUIDs go wrong.
A 36-character primary key takes more space than an integer and breaks join performance on large tables. URLs containing UUIDs are unsightly. Users can't read them aloud. For internal IDs they're fine; for user-facing slugs, prefer something shorter (a base58-encoded random ID, or a slug derived from the content).