Over time, UUID has been massaged and adapted to fit many different applications, with the actual similarities between different versions whittling down to 2:

Over time, UUID has been massaged and adapted to fit many different applications, with the actual similarities between different versions whittling down to 2: - data types used in binary representation (in order: u32, u16, u16, u8, u8, u16, u32) - canonical string representation (xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx) I am of the opinion that this has diluted the usefulness of UUID, especially in specific circumstances. With this in mind, ULID was designed for applications that require the following: - distributed ID generation amongst loosely coordinated servers (ie. those that don't have incentives to maliciously manipulate timestamps) - sortability of items with assigned ID without any additional information (ex. no additional db joins/requests) Finally, ULID was designed with the explicit intent of being as character efficient as possible, for use in URLs and such. By using the Base32 alphabet, it uses fewer characters than UUIDs, optimizes for human readability/clarity (Crockford's modifications) and remains case-insensitive. For any API driven web-app where both the client and server can generate new data, ULIDs can be ideal. A lot of people are already using something similar. I thought it would be nice to standardize it as a drop-in replacement.