←back to thread

ULID: Universally Unique Lexicographically Sortable Identifier

(packagemain.tech)
68 points der_gopher | 2 comments | 01 Dec 25 20:45 UTC | HN request time: 0.774s | source
Show context
sedatk ◴[09 Dec 25 22:26 UTC] No.46211578[source]▶
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.

replies(6): >>46212131 #>>46212144 #>>46212658 #>>46212724 #>>46213359 #>>46213609 #
1. unscaled ◴[10 Dec 25 02:32 UTC] No.46213359[source]▶
The monotonic behavior is not the default, but I would also be happier if it was removed from the spec or at least marked with all the appropriate warning signs on all the libraries implementing it.

But I don't think UUIDv7 solves the issue by "having less quirks". Just like you'd have to be careful to use the non-monotonic version of ULID, you'd have to be careful to use the right version of UUID. You also have to hope that all of your UUID consumers (which would almost invariably try to parse or validate the UUID, even if they do nothing with it) support UUIDv7 or don't throw on an unknown version.

replies(1): >>46213549 #
2. sedatk ◴[10 Dec 25 03:07 UTC] No.46213549[source]▶
UUIDv7 is the closest to ULID as both are timestamp based, and UUIDv7 has fewer quirks than ULID, no question about it.

I agree that picking UUID variant requires caution, but when someone has already picked ULID, UUIDv7 is easily a superior alternative.