UUID and ULID Generator
Random and time-ordered identifiers, with what each kind is good and bad at.
UUID version 4
b1f37224-86bd-4da4-a210-235d8aa8bb54 cb386f42-9aff-4849-a193-24bbf0d6f1f6 f422c2a7-1869-4266-858e-e2e1fde57366 ca406fd1-2643-47dd-910e-0580081317c1 5707c410-1676-4524-8551-0ade449af1cf
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.