Sonyflakes are generally more useful in massive scale environments as you won't run into conflicts due to the "machine-id" part (which defaults to the lower 16 bits of the private IP address).
There are more differences (128bit vs 64bit, rng vs time-based), I think they have different use cases.
More structure actually increases
the chance for collisions. Because at that scale the chance of bit errors is dominating the equation. More rng protects against that.
Not exactly,
They can be sorted, by default, only down to a millisecond, but you can use a monotonic generator to have them sorted, even if more than one Ulid is generated within a millisecond.
Other than that, they have 80 bits of randomness, enough to be unique even if millions are generated per second.
I'm curious, if you don't mind my asking. What are you building that requires that amount of scale? These are heavy hitting IDs (but of course you know that).
To be honest for the application I didn't want to expose a database serial (otherwise you'd know you're user #100, for example) or use UUIDs, so it's less about scale and more about obscuring ids. The library is well suited for huge scale scenarios nonetheless.
If it’s unique it’s a privacy leak. I’m not going to debate that, it’s common knowledge.
UUID was changed in the 90s to be a hash of this instead and later to just be a completely random number because there are so many bits the likelihood of a single duplicate being generated before the sun has swollen enough to consume the earth is slim so you don’t actually need these schemes to provide a unique number.
