Now that UUIDv7 is lexicographic, does that mean there is no use for ULID?
1–8 of 8 posts
Re: Now that UUIDv7 is lexicographic, does that mean there is no use for ULID?
#2- 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?
Re: Now that UUIDv7 is lexicographic, does that mean there is no use for ULID?
#3- 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 ac…
Some databases directly support uuid, so they can save it as the binary data itself.
Re: Now that UUIDv7 is lexicographic, does that mean there is no use for ULID?
#4- 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 ac…
Some databases directly support uuid, so they can save it as the binary data itself.
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)...)
Re: Now that UUIDv7 is lexicographic, does that mean there is no use for ULID?
#5HN guidelines say "please use the original title, unless it is misleading or linkbait; don't editorialize".
This should probably be titled "uuidv7: A JavaScript implementation of UUID version 7"
Re: Now that UUIDv7 is lexicographic, does that mean there is no use for ULID?
#6RFC 9562 to add ULID-variants to the UUID spec is taking forever to standardize! Can't we just get it through already, and pester all mainstream frameworks and databases to support it please?
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!
Re: Now that UUIDv7 is lexicographic, does that mean there is no use for ULID?
#7- 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 ac…
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.
Re: Now that UUIDv7 is lexicographic, does that mean there is no use for ULID?
#8[dead]