> It is worth noting that the newest proposed standard for unique identifiers, UUID v7, aims to address the sortability and database performance issues of older UUID versions by adopting a similar time-ordered structure to ULID.
Whenever ULID comes up, I need to remind that it has a sequential ID generation mode in its spec which is prone to conflicts on multi-threads, processes or hosts which kills the purpose of a "universal" identifier. If you need a sequential ID, just use an integer, preferably one that's autoincremented by the database.
It's best to stick to UUIDv7 because of such quirks of ULID.
I have always been a bit hesitant to use UUIDs with timestamps as it can be a security issue if the IDs are public. For example getting the age of a user account just from the id. I will say, however, that I have not heard of any major incidents stemming from this.
Interesting article noting how ULIDs solve database index fragmentation caused when using UUIDv4. However, for extremely high-volume writes, ULIDs create "hot spots" at the current timestamp index location, potentially causing contention. The article notes that UUID v7 (newly standardized) adopts the same time-ordered approach, validating ULID's design.
As others already pointed out, UUIDv7 is a solid choice and if you don't like the default representation, you can encode the underlying byte array with base62 for example, to get short, URL-friendly IDs.
12 comments
[ 3.7 ms ] story [ 29.7 ms ] thread> Why not use UUID7?
> "ULID is much older than UUID v7 though and looks nicer"
For those unfamiliar, UUIDv7 has pretty much the same properties – sortable, has timestamp, etc.
ULID: 01ARZ3NDEKTSV4RRFFQ69G5FAV
UUIDv7: 019b04ff-09e3-7abe-907f-d67ef9384f4f
Yeah, I would go with UUID v7 at this point given that it's part of the UUID RFC https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-vers...
It's best to stick to UUIDv7 because of such quirks of ULID.
for those also learning