Ulid should wholly be deprecated now that uuidv7 is available.

Ulid have a short representation that uuid7 could use but doesn't define. Also, has UUID7 been standardized already? I thought it was still in the pipeline.

As a Microsoft SQL user (not everyone can choose their DB..), UUIDv7 has the issue that people will (understandably, but ignorantly) store it in "uniqueidentifier", which shuffles bytes around and are no longer sorted on time... ..

There is even a specific Microsoft SQL-time-ordererd UUID format which is sorted after byte shuffling..

We store ULID in binary(16). Works nicely. Only difference from UUIDv7 is the version bits..

Couldn't you put UUIDv7 in byte(16) and get the same feature?

I found today a PHP UUID library that does one they call UUIDv8 which has more time (like ULID)

Yes, one could. The problem is most programmers who are not aware of this (probably most), will see the UUID and make assumptions that uniqueidentifier type is the most suited one.

They are less likely to take a ULID and store it in binary(16). (Might store it in char(26), which is less storage efficient but is still sorted.)

Apart from that I happen to LIKE the fact that I can very quickly see the difference between a random identifier and a sorted identifier, they have quite different characteristics after all.. Although I guess people might eventually get used to the initial bytes being 0 on UUIDv7, or just learn to recognize the version bytes..

On that topic, why are the 8 fixed bits of a UUID not concentrated on the same byte. Perhaps the first one. Huge mistake..

ULID has many advantages over UUIDv7, including (but not limited to) higher timestamp granularity, and more usable canonical string representation.

Ok wow this blog post was really illuminating. Thanks for pushing back on my preconceived idea that UUIDv7 is the 'official' version of ULID

https://blog.daveallie.com/ulid-primary-keys

Why? It does not suffer from some of the UX issues this article discusses.