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