UUID and ULID Generator
Random and time-ordered identifiers, with what each kind is good and bad at.
UUID version 4
68632080-ac09-46f1-adc5-dde7f9b778e9 4706c18a-6483-4a8d-b941-0b1638ee6bcd df6ff1e4-86c8-4dc1-9913-2087e0395192 af52a416-4f03-469c-beb4-31d3e925b91e 523e7396-5e80-4d0e-90a3-b46e754532f5
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.