Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
* 48 bits timestamp gives enough space for the next 9000 years.
[0] https://github.com/ulid/spec
I also spent some time evaluating them, and came to the conclusion that KSUIDs (https://github.com/segmentio/ksuid) were strictly better than ULIDs.
The differences aren't huge in practice, but the ULID spec has a couple of highly questionable choices. Specifically, according to the spec:
1. The first time you generate a ULID in a given millisecond on a node, you should fill in the random component randomly.
2. But if you generate more than one ULID per milliscond, subsequent ULIDs should use the first ULIDs random component and just increment the least significant bit.
3. If that would overflow, then you just can't generate any more ULIDs that millisecond.
The goal is that ULIDs will be strictly sortable even when you're generating multiple per millisecond...except for that to work, you'd have to only generate them in a single thread (or at any rate on a single node). If you're just incrementing a numbers on a single node, then uh, why not just use an autoincrementing integer column in a DB? Of course, if you're generating multiple IDs per millisecond, you're probably using multiple nodes, and if you are, then wall clock skew means the IDs will never be strictly sortable. Except actually it's even worse than that; even if you ARE only using a single node, you still can't really know how any given arbitrary ULID was generated, so you can never rely on the sorting guarantee. Meanwhile, a compliant ULID generator has to have state and, if it's going to be called in a multithreaded way, to deal with some complex race conditions.
Meanwhile, you could get 100% of the benefits and none of the drawbacks by just...using random bits for the random component every time.
Anyhow, the idea of slapping a timestamp and a random string of bits together is a good one. I just think the KSUID spec is a bit better thought out.
Before starting this, did you look at the flaken crate? If so, any concerns or notable differences? https://github.com/bfrog/flaken