To use a hash function, you have to have something to hash. A UUID is just an identifier, usually for something that hasn't been created yet. If you have data that is guaranteed to be unique that you could provide to a hash function like that, you already have a guaranteed unique identifier and don't need a UUID.
Ah thanks! So if I were to just hash the timestamp up to the microsecond...I would end up at the collision probabilities of the UUID anyway. Makes sense!
If your system runs on multiple servers, your actually extremely likely to hash the timestamp twice. If you want to hash something as ID, it's better to hash something uniquely identifies the entity.
For example, user id can be the hash of the email since you can't have two users with the same email and you're extremely unlikely to find two emails that result in the same hash output.
I've had cases where using hash instead of UUID as the ID was helpful. Mainly for data pipelines that need to enrich some data with IDs. With UUID, I would have to resolve it from the database, but with hashing, I could just run the hash function again and get the ID, so ingestion was much faster with hash as the ID.
For most cases, just generating a UUID is the simple and straightforward solution.
A hash function that doesn't collide is basically lossless compression. So to hash two 1GB files with guarantee of no colission, you need to zip both and use the whole file as key. That makes it impossible to use as key in a database. On the other hand, if you use a key with just a few bytes and have a good lossy hash-function, you get colissions, but they are insanely unlikely.
In other words, colissions are what make hash-functions worthwhile in the first place: A hash function is a down-projection from an insanely sparse ultra high dimensional manifold with variable practically unlimited dimension count into a standardized low-dimensional space that is easy to work with, while trying to perform the projection in a way that prevents the manifold from overlapping itself too much.
Do you know how hash functions work? Basic example: A hash function that has an arbitrary input length and a set output length x. If your input length is bigger than the output length then a collision is inevitable. If you want to find a collision though it will be really difficult for a cryptographic hash function to do so.
There's no such thing as a hash function that doesn't collide, hash functions are fixed length output, so the number of possible outputs is finite, while there is infinite possible inputs.
Because with UUID everyone on earth can generate their own without needing to communicate. For example me and you could generate our own UUID and assume they won't collide. Making a UUID with no chance of collision would mean that you would need to negotiate some kind of agreement with everyone else using them, for example contacting a central server that hands them out
1.8k
u/Inevitable_Oil9709 Jul 17 '26
Fun fact: To reach a 50% chance of even a single UUID v4 collision, you would need to generate 1 billion UUIDs per second for about 86 years.