UUID and ULID Generator
Random and time-ordered identifiers, with what each kind is good and bad at.
UUID version 4
8db7d187-5b2f-4ab4-aab0-5d7bdb774ea4 a21274ff-ee00-4dd1-ae73-2792b2c47b07 354d7854-d2d8-4760-a005-98a6a80d1a76 d3429201-8ee8-4030-859a-0bd75ffccbca 319043e3-5451-4f03-acc5-5b2bb7cf3c33
Which one to use
- UUID version 4
-
The right default. Nothing about it can be read back: no time, no
machine, no order.
The wrong choice for a primary key in a large table. Consecutive rows land in unrelated places in the index, which makes inserts slower and the index larger than it needs to be. - UUID version 7
-
A version 4 with the clock in front. Sorts by creation time, so an
index grows at one end.
The same 36 characters and the same shape, so a column, a type and a library that hold a UUID hold this one without changing. The cost is that the creation time is now readable by anyone holding the identifier. - ULID
-
The same trade as version 7, decided before version 7 existed.
26 characters, no hyphens, case-insensitive.
Shorter, and easier to select with a double-click or read aloud. Against it: a community specification rather than an RFC, and a database with a native UUID type will not store it as one.
Generated on this server with the operating system's random source, sent once, and not stored. Reloading gives different ones; there is no way to get these back.