ULID's claim according to their official documentation are the above of which everything is taken care of by UUIDv7 officially now. Why should I or not shift back to UUIDv7?
Having had to massage lots of data with base62 and other weirdnesses, this lowest common denominator approach is a really big selling point.
People often bikeshed about shaving a few bytes off the ID or something, but in most applications this is not very important and data storage formats are usually compressed so costs are about entropy not alphabet.
So whether you use ULID or UUIDv7, save it as binary(16) in MSSQL.
(There is a special custom UUID implementation someone made for MSSQL that will sort time-ordered on MSQL but nowhere else; IMO that is too niche...just use binary(16)...)
This should probably be titled "uuidv7: A JavaScript implementation of UUID version 7"
The RFC https://www.rfc-editor.org/rfc/rfc9562 lists 16 prior ULID schemes, and it is obviously not exhaustive because I've bumped into lots of hand-rolled schemes over the years.
In this case, standardization helps. Being able to have conversations about using UUIDv7 rather than having to bikeshed on the merits of which of the prior schemes fit and why would be sooooo much easier in corporate environments!
