Deprecate in favor of UUIDv7
booch opened this issue · comments
I just read about UUIDv7. It's a proposed IETF standard, in "last call". Other than the base32 encoding, it's got everything we want from ULID. UUIDv7 will be more widely accepted and available to developers.
I propose that we declare victory, and allow the UUID spec to take over the effort from here on.
See #85 for some additional discussion.
ULIDv7 has weaker rules for each part of the ID, and sacrifices 4 bits of entropy to a static version identifier. It's different enough that I don't think it makes sense to "deprecate" ULIDs.
4 bits
6 bits. Still, UUIDv7 solves some ULID issues like predictability of the monotonic factory, and UUIDs being better supported in databases in general
ULIDs don't have predictable monotonicity unless generated as such, and database support is a red herring 🤷
ULIDs don't have predictable monotonicity unless generated as such
ULID spec is unclear about that (#80) but some implementations are monotonic by default in spec-described unsafe way (like symfony/uid)
database support is a red herring 🤷
It's not, it's the reason I'm no longer using ULIDs for new projects
ULIDs and UUIDs are represented in databases identically: as 128bit numbers both.
Whether or not IDs have monotonic entropy is opt-in by the producer. And whether or not predictable monotonicity is a problem is a function of use case (it is not always a problem).
ULIDs and UUIDs are represented in databases identically: as 128bit numbers both.
If stored in binary, you can't manually query a ULID given its string. With UUID even without db support you can simply remove dashes and query as a raw hex
You all probably already know, but just in case, RFC 9562 was published a few days ago (May 7, 2024). RFC 4122 is obsolete and UUIDv7 is now official.
https://www.rfc-editor.org/rfc/rfc9562
https://datatracker.ietf.org/doc/rfc9562
ULIDs and UUIDs are represented in databases identically: as 128bit numbers both.
If stored in binary, you can't manually query a ULID given its string. With UUID even without db support you can simply remove dashes and query as a raw hex
They start as 128 bits but in practice UUIDs inevitably end up as raw 36 char strings, annoying AF. ULIDs are shorter by 10 chars and still mean something
Exactly, string encoding of ULID is superior to UUID.
and still mean something
I don't understand this argument
Exactly, string encoding of ULID is superior to UUID
You can encode UUID to Base32 too if you want. Converting UUIDv7 to Base32 even makes it a valid ULID
ULIDv7 has weaker rules for each part of the ID, and sacrifices 4 bits of entropy to a static version identifier. It's different enough that I don't think it makes sense to "deprecate" ULIDs.
Just for clarity, confirming that you probably meant UUIDv7.