UUID and ULID Generator
Random and time-ordered identifiers, with what each kind is good and bad at.
UUID version 4
8a1a9a7e-6f16-44df-9e21-7ed81315bf63 270da63e-2ffb-4f24-b6be-2f52bf9e7ba0 7ce33814-ad9f-4bab-af7a-a79fc7743c05 7fbc033b-f2ed-4820-a727-7bd169eefbe3 aa4660dd-2195-4da0-a93a-5bfcb979a018
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.