2 ms·
One thing to be aware off is that the ULID spec only guarantees ordering up to millisecond precision. Most implementation additionally guarantee ordering of the
by valzam 4y ago
One thing to be aware off is that the ULID spec only guarantees ordering up to millisecond precision. Most implementation additionally guarantee ordering of the 80 random bits for absolute ordering but only IN PROCESS. If you have many clients concurrently producing data and generating ULIDs you can run into out-of-order rows. If this matters or not is ofc application specific.
One use case of ULIDs is as event IDs in distributed systems. If the producers are horizontally scaled Microservices you might generate events with reversed ULIDs compared to their logical order.
Ordering in distributed systems is anyway very hard but be aware that ULIDs are also no silver bullet
- lukevp 4y agoI think this is a bit of a red herring. ULIDs are not meant as a replacement for a lamport timestamp or something. The accuracy to the millisecond would only be correctly ordered if the clocks were perfectly synchronized anyway. I interpret the purpose of the timestamp based id as allowing denser clustering in b-trees vs random key data, and that’s about it. The timestamp can only be used as a relative ordering when processing multiple events from the same client, and even then not completely (client clock could change).