Hacker News Reader

Comment by brdd | Hacker News Reader

We have used ULIDs in production for over a year now-- and have generated millions of these.

First, the main benefit of ULID is that you can generate the IDs within your own software rather than rely on the database. We can queue them or even reference them before they land in the database. The traditional roundtrip has been eliminated.

Secondly, being able to sort ULIDs is a nice plus, although not that big of a deal. It makes it relatively easy to shard or partition databases, and it provides a convenient sort if you're not looking for extreme accuracy.

ULIDs are also shorter and slightly more user friendly than UUIDs.

In some circumstances we found the actual implementations to be slightly lacking. For example, the JS library for ULID once returned a 25 character string rather than the standard 26 characters, causing a big ruckus that we had to manually resolve.

View on HN

> First, the main benefit of ULID is that you can generate the IDs within your own software rather than rely on the database. We can queue them or even reference them before they land in the database. The traditional roundtrip has been eliminated.

No you cannot, unless you're running a single threaded server process on a single machine. What you can do is _gamble_ that you probably won't have a collision, which is the same thing you could do with regular UUIDs and you'd be (nearly) guaranteed to never hit a conflict with UUID4 (or probably UUID1/2 if you trusted your mac address uniqueness).

You may find this gamble acceptable and many people do, but you should be aware that pre-generation of UUIDs on independent systems without coordination is not a solvable problem - all attempts to do so rely on the extreme unlikelihood of a collusion to feel good about it or use some coordinated information (like a guaranteed unique mac address).

(Again, if it's good enough for you, right on - but it isn't theoretically safe)

> No you cannot, unless you're running a single threaded server process on a single machine. What you can do is _gamble_ that you probably won't have a collision

This seems like a pointless distinction.

If I did the math right, you can generate 1,000,000 ULIDs per second (1000 per millisecond) for around 50 million years before you can expect to hit your first collision.

I don't know about you, but I'm pretty sure any system I build won't be running 50 million years from now. Not to mention that the timestamp portion of the ULID will overflow in a mere 9000 years.

I did the math too after reading your comment and got the same result: on average, with 1,000,000 ULIDs per second, I'll wait 50 million years before hitting the first collision.

Here is the Python code I used: https://gist.github.com/ngrilly/565bd27f4ad63244f72578844bca...

But I'm curious to know how you computed this?

I agree that collision is not an issue.

On the other hand, your consistency assumptions may be broken if you rely on the sort order for causality relationship.

You can have ULID1 < ULID2 and yet the event associated with ULID1 may be caused by the ULID2 event.

Does your math rely on perfect entropy on machines you don't control?

Yes. I did the math and got the same result, relying on a perfect entropy hypothesis.

The point was that this was not an advantage of ULID over UUID. You need 2.7 * 10^18 v4 UUIDs for a 50% collision chance.

Did you account for long tail events?

I don't see how it is at all a gamble if you understand the trade-offs.

If there is no fatal flaw with the inaccurate/non-deterministic sorting that wall-clock prefix provides and one is utilizing optimistic concurrency (strict create on PK, abort/retry on conflict), I don't see how it is unsafe

The gamble is the removal of a central key registry. If you are assigning these UUID/ULIDs as... UIDs then you need to be able to assign them uniquely... if multiple servers/threads/whatevers can generate and assign them independently then there is a chance you'll suffer from ID collision... it's incredibly rare though.

But with optimistic concurrency, why is this a gamble? It's an overhead that comes as a result of the trade-offs, sure, but it's a finite cost. Collision can be handled without breaking anything at the cost of implementation complexity.

> What you can do is _gamble_ that you probably won't have a collision, which is the same thing you could do with regular UUIDs and you'd be (nearly) guaranteed to never hit a conflict with UUID4 (or probably UUID1/2 if you trusted your mac address uniqueness).

UUID4 is no more safer than ULID since they both rely on randomness.

Reply on news.ycombinator.com