Now that UUIDv7 is lexicographic, does that mean there is no use for ULID?

Re:Now that UUIDv7 is lexicographic, does that mean there is... by a-s-k-af on Monday June 17, 2024 @08:41PM (#40712873)

- 128-bit compatibility with UUID - 1.21e+24 unique ULIDs per millisecond - Lexicographically sortable! - Canonically encoded as a 26 character string, as opposed to the 36 character UUID - Uses Crockford's base32 for better efficiency and readability (5 bits per character) - Case insensitive - No special characters (URL safe) - Monotonic sort order (correctly detects and handles the same millisecond)

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?

[ Parent | on HN ]

Re:Now that UUIDv7 is lexicographic, does that mean there is... by stop50 on Tuesday June 18, 2024 @01:38AM (#40714373)

Some databases directly support uuid, so they can save it as the binary data itself.

[ Parent | on HN ]

Re:Now that UUIDv7 is lexicographic, does that mean there is... by dagss on Tuesday June 18, 2024 @02:27AM (#40714638)

Do NOT do that with MS-SQL. The uniqueidentifier type shuffles byes around and does not give you the ordering you want.

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

[ Parent | on HN ]

Re:Now that UUIDv7 is lexicographic, does that mean there is... by willvarfar on Tuesday June 18, 2024 @03:04AM (#40714878)

One big practical benefit of UUIDv7 is that it is hex, and simple substring extraction and from_hex functions, which are available pretty much everywhere, will be able to extract the timestamp portion from the high bits.

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.

[ Parent | on HN ]