UUID Generator

Sixteen bytes, printed as thirty-six characters

The value is 128 bits. The string everyone calls a UUID is one way of writing those bits down, and the hyphens in it carry no data at all — they group the hex into 8-4-4-4-12 because a solid run of 32 characters is harder to read aloud and harder to compare by eye. Four characters of that string are decoration, which is worth knowing before a column is sized:

f47ac10b - 58cc - 4372 - a567 - 0e02b2c3d479
      └──────┘   └──┘   └──┘   └──┘   └──────────┘
        32 bits  16     16      16         48

        4372  the leading 4 is the version field
        a567  the leading a is the variant field

        128 bits of value, 36 characters of text
        the same value in base64:  22 characters, no hyphens

Stored as text, a UUID wants 36 characters and a fixed-width column, and the case is a decision you have to make once and apply everywhere: a comparison between an uppercase and a lowercase spelling is a comparison between two different strings. Stored as bytes, the same value takes 16, the database can index it properly, and the formatting question disappears because nothing prints it until something needs to read it.

Unique is not ordered

A database keeps its rows in a structure sorted by the primary key, and an index on a random key pays for that in every insert. A counter appends at the end, where the next free page already is. A random value lands somewhere in the middle of the tree, so the page it needs is probably not in memory, a read has to happen before the write, and the pages that do get cached are spread across the whole index instead of clustered at one end.

Whether that matters is a question about the shape of the table rather than about size. A table with a few thousand rows and modest write rates will not notice, and the convenience of any client inventing its own identifier without asking the database first is worth more than the index ever costs. A table taking thousands of inserts a second notices immediately, and the usual fix is an identifier whose leading bits come first in time — a version that puts a timestamp where the index can use it, keeping the randomness after it.

There is a second cost that has nothing to do with performance: a random key sorts arbitrarily, so it can never be used to page through records in the order they were created or to shard them by range. Whatever the key is made of becomes the only ordering the table has, and choosing it is choosing that.

The same name should give the same id

A random identifier is a name for an event, not for a thing. Run an import twice and the rows get two different identifiers, so the second run duplicates everything the first one wrote. A deterministic version solves it by taking the thing's natural key — a URL, an email address, a path — and hashing it together with a namespace value. Same input, same identifier, on any machine, in any process, forever.

The namespace is what keeps two kinds of thing apart. Hashing a bare URL would give the same value as hashing any other string that happened to be identical, so the namespace says which family the name belongs to, and two families that both contain the string /index produce different identifiers. The standard publishes a handful of namespaces for the obvious cases and expects you to invent your own for your own data.

It is not a security boundary, and it is not a secret. Anyone who knows the namespace and the name can compute the identifier, which is the point — it is a way of agreeing on a name without coordinating, not a way of hiding one. Where the identifier does have to be unguessable, a random draw is the right tool and this one is the wrong one.

What actually goes wrong

Duplicates almost never come from the randomness. They come from a column sized for 36 characters when something upstream wrote 32, from a truncation somewhere in a pipeline, from a case-insensitive collation on one side and a case-sensitive one on the other, or from a client generating identifiers with a seeded generator that produces the same sequence on every run. A collision report is worth reading as a plumbing bug until something proves otherwise.

The other failure to avoid is choosing a version that publishes something you did not mean to publish. A version built from a host address and a timestamp embeds a hardware identifier and the moment of creation, both of which survive into any document or URL the identifier is pasted into. Those are the versions to read and not to make.

Two nearby tools cover what this one does not. A Hash Generator produces a digest of bytes, which answers a different question in a similar-looking length, and the Password Generator is where an unguessable string belongs — an identifier is a name, and a name that grants access needs an expiry, a single use, and a hashed record rather than the string itself.