Deprecate in favor of UUIDv7

[booch]

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.

[booch]

See #85 for some additional discussion.

[peterbourgon]

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.

[arokettu]

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

[peterbourgon]

ULIDs don't have predictable monotonicity unless generated as such, and database support is a red herring 🤷

[arokettu]

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

[peterbourgon]

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).

[arokettu]

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

[fabiolimace]

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

[liquidcarbon]

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

[bbrtj]

Exactly, string encoding of ULID is superior to UUID.

[arokettu]

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

[sydbarrett74]

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.

[jpickwell]

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

PostgreSQL has a built-in uuid column type that hides the value's binary storage. You can query using the string representation of a UUID without sacrificing the binary storage of the UUID. For ULIDs, you could store them as uuid and just do a trivial conversion to/from UUID when querying the DB.

As for the lack of DB support, ULIDs can be trivially converted to hex just like UUIDs, so whatever your argument is, it's moot.