Hacker News Reader

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

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.

Did you account for long tail events?

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.

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.

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