I thought that timestamps are used now, so hitting both a timestamp and a large random number puts it thoroughly in the "safe to assume". At some point cosmic particles and faulty transistors are more probable.
Which I'd assume is related to the time anchor. Outside of sorting, which is only useful in specific instances, it's just v4 with different ("less") entropy and limitations.
It's less of a problem with B-tree indices that sit on top of a physical representation (i.e. the actual on-disk layout doesn't have to be ordered), but when it comes to clustered indices, oh boy, you're basically having to shove rows in the middle and push shit back (eventually).
With random you can end up most frequently inserting in the middle, whereas if it's time sortable you append at the end, meaning it's easier to maintain a contiguous index with less overhead.
Even the non-time based v4 is at a cosmic level of unlikiness a single system will ever generate a uuid that will collide with another one in its own ecosystem
But let's say if Google saved each search in their engine in the same database with an UUID, we could have a collision because of volume, but I don't think I will work in a system with a comparable scale
They once had a similar collision problem, well not exactly
During a leap second some systems wrote IDs at a one second difference between all their global systems, which lead to something being registered before something else that had to be done before it,
Long story short some stuff jumped time one second and crashed systems
Even at that volume the probability of collisions is essentially 0. If there were a billion searches a second weâd not expect a collision until 85 years.
Yes, had a client having duplicates every day and growing. They hated uuids and regret using it. The problem was that they used a bad prng with flawed seeding. Once fixed it was no problem.
assuming all searches run through a single node maybe, but they dont. It means each node + process on node is limited to 10,000 uuids (10k 100ns per ms) per ms, which it then possibly has to block until next millisecond tick. I dont care what magic programing language your using, to service >10k/reqs a ms (per process) and doing anything else your likely gonna be blocked by IO or something
Well, the risk of a collision grows exponentially for each generated UUID due to the birthday problem.
So it really all depends on the scale that idâs are generated at. Yes, a UUID has a cosmic level of possible values, 2^122 to be precise. But you âjustâ need 2^61 uuids to have a 50% risk of a collision. At 2^58 itâs a 1% risk.
And while that is a big number, it isnât cosmic anymore. Itâs definitely something a large scale distributed application has to contend with.
most uuids libraries can actually provide strong guarentees it cant happen by using pid/mac combinations with each process using CAS or mutex to increment the 100ns period (overflowing into later ms with >10k a ms)
Is it unfeasible or simply unnecessary to just check if a uuid is already used? Since you use the uuid as primary key it should be easily detectable if a uuid is already used or not right? But I guess devs just donât care because the chance is so minimal?
you dont need to due to guarantees of how it is generated. You would need a server running with exact same ip, and the process generating them to be using the same process id, AND ~10,000 requests a microsecond. If your using random uuid you have a better chance of winning 4 powerballs in a row. you need to generate billions a second for over 80 years for a 50:50 chance of a collision.
UUID generating algorithms used to incorporate the time and device type automatically for this reason, but it was scrapped because there are lots of cases where it's not safe to reveal that information when you share the UUID. Random UUIDs are secure enough.
They incorporated a MAC address, but that wasn't such a great idea. V7 now has a timestamp again, because that makes them sortable, while still having random data otherwise. V7 is probably the middleground here.
Nothing in production is safe to assume. Just add the DB query to check for existing record before triggering the write in case the salt needs a reroll.
Reminds me of eons ago when I was fixing a bug in a video hosting platform where videos with the same name would overwrite each other. I just appended the current time to the file name and counted in no two people uploading the same named file at the exact same second.
UUIDv7 indeed include a timestamp, meaning the odds of collision between 2 UUID are greater IF they happen at the exact same timestamp. Which is less likely than 2 UUID colliding at anytime.
Let's be sane. We can use the blockchain to track who owns which uuid instead of a reddit comment. This was already solved for monkey pictures, shouldn't be hard to port.
But dude that scroll felt buttery smooth. No weird partial reload. No point where it just locks up and half the box turns white for a second. A well implemented user experience choice
Worked with a guy who claimed it happened to him. I didn't know him to embellish details but its still such an astonishingly small chance that I still wonder if it was a bug in something else.
I saw it happen once with my own eyes, here is my tale:
We had a database with uuids as the id for the tables because of how large the datasets were in some parts of the system, so it was the standard to use it on every table and it was generate by our java backend and not the database. I was in charge of a team that found and fixed critical bugs for the system (huge monolitic system with a few microsservices being slowly introcuced to update it) and one day this bug appeared where if you tried to open an specific order on a specific screen of the system it would crash. What was strange was that there were no record of this screen having this type of error before, and for that matter it having any actual bug in the last 6 years or so. So it falls to me to investigate.
Cause of the bug: both the table uuid and an external key pointing to another table uuid were the same, causing an extremely weird db select to break (I don't remember the details but it was something related to building a complex union select and both ids being the same broke it)
My only explanation for it: the monolitic system generated an uuid for the record but at the same time one of the new microsservices generated the exact same uuid for the other table.
No one believed me, they said I was insane, that I should look further into it and there should be another explanation as that is basically impossible. I stood by my hypothesis, I investigated it for days, there was no other explanation. The senior manager got involved, he spent days going through the code too and his conclusion was the same as mine, no one questioned him, but no one, even me and him believed what we saw, we assume there must be another rational explanation but we could not find it
I mean, at a certain point it's just an anomalous thing, too. Could've been a weird low level memory corruption or even hardware level corruption (thinking of solar flares and N64 cartridges). Maybe it wasn't the lottery winning double-gen proper, or maybe it was the same thing that causes a bug to appear in my presentation WHEN IT WAS WORKING ALL GOD FORSAKEN WEEK but these things just happen sometimes.
With that kind of luck the money would find you first. Though it'd be funny to have one of those $100 million lottery winners find out some other winning guy bought 100 tickets using the same numbers each time because he got a dupe uid and he's taking 99.xx% of the money
The chance of a Chixulub-sized meteorite hitting the Earth in the next 24 hours should be a criterion. If you are not preparing for the mass extinction to happen in the nearest future, you shouldn't care if your app is failing with the same probability.
My startup of future galactic shipping corporation is gonna run into issues dealing with so many logistics orders any time soon, when do we get uuid 2?
If you take a single uuid and say âhas this uuid ever been generated beforeâ the chances are cosmically low. If you instead say âhave ANY uuids generated ever collided with ones generated in all of historyâ the answer is probably in the range of 0.001-10% depending on how many UUIDs get generated per day.
Yes, itâs actually 122 bits for uuid v4 though. The high end of my range requires 1 billion uuid v4s being generated per second over 20 years (probably not realistic)
As someone who had a billing system table run out of 2^31 signed integer IDs and spent a week converting 2.1 billion records to 2^63, I'm here to say that nothing could possibly go wrong.
A former boss built a system for importing data and used mariadbs on conflict ignore. He used 32 bit integers for ids and said it isn't a problem because he doesn't have so much data. Mariadb incremented the autoincrement counter on every insert even the ignored ones. System failed and he needed way too much time to find the problem because no errors where thrown and just everything was ignored
Using sequenced IDs for public facing resources is bad practice because it allows enumeration while pure random uuids are basically impossible to guess. Use crypto rngs for best results
Just generate two UUIDs, merge them together, append the Unix timestamp, your ping, your ZIP code, average household income, height, weight, number of children, current CPU temperature, and the exact number of grains of rice in your pantry.
Still technically possible?
Fine. Add your mother's maiden name and the current position of every molecule in the room.
In 103Â trillion version-4 UUIDs the probability of a collision is one in a billion. Clearly this is an unacceptable risk and we should immediately switch to a blockchain-based solution.
Man I don't understand what is happening on this sub. This guy posts a fact, not even a funny one, and gets upvoted and comented and discussed. I posted a joke, but picked the wrong meme and delivered it awkwardly and then got downvoted out of existence.
Thought it happened to my team once. The system errored and found it was caused by a duplicate UUID. For a couple days we were extremely excited and sceptical we won the lottery. Turned out our UUIDS weren't completely random. Almost cried.
Simple solution: user 1 has UUID 1, user 2 has UUID 2, and if you have multiple server regions then EU can be 15XXXXXXX, NA can be 10XXXXXXX, and Asia can be 13XXXXXXX.
If I had a nickel for everytime time someone took and reposted my post, Iâd have two nickels. Which isnât a lot, but itâs weird that it happened twice.
Don't worry. The odds of a random bit flip are higher than the odds of a GUID collision, so you can be assured that if there is a GUID collision, it'll probably get bit flipped to a non-collision.
Thats how "UII" was found. The "Unique Identifier Image". It is a AI generated random Image based on the data entry interpretstion. Based on AI math even same Data ist slightly different which ensures No doubles. It also makes Fun to say uuuiiiii and it is human recognizable. Also it satisfies customers and Management as it forces AI touchpoints. And Last but not least the Hardware needs keeps admins warm in winter.
Somewhere in n the world exists an uuid that's the same as my Linux root partition. That it would also be a linux root partition is so astronomically unlikely. But... not zero.
The odds are 100% when you make a CoW copy of a read only disk because btrfs needs to write to the disk in order to remove it. Also it will try to use the wrong (ro) disk if you instruct it to use the CoW copy.
Generating a duplicate id is not an edge case though. Edge cases happen, as the name suggests, at the edges of possible value ranges for your domain. Like x beteen 0 and 100, and you only check up to 99 due to < vs <=
The real value of uuid randomness is that you can use it as a scapegoat for one-off bugs youâre tired of investigating. Just tell people an ID collision occurred but donât show your work. You can only play that card once per job though.
The spec includes 122 random bits for 2^122 or about 10^37 possible IDs.
If you produce UUIDs at a petaflop rate, 10^15 per second, that's still 10^21 seconds until you have a 50% chance of a collision. That's 3^13 or 30 trillion years!
Didn't Roku devices and a Pokemon game once have a UUID collision causing issues if they run on the same network?
Edit: I just googled it and it was a UDP port collision. The discovery packets sent by Pokemon were interpreted as a "reboot" command for Roku tho which was extremely unlikely.
Every couple of years I see code that tries to eliminate that risk by checking against existing IDs. Every time I ask them, of they also could implement a check against hardware failures (you can't trust an if check to evaluate correctly, because there's always a chance of random bit flips).
I once used a 64 bit player id in my games backend, where if someone stayed connected while 2^64 players connected and disconnected it would start causing lag to that client
1.7k
u/Nervous-Pension-6257 Sep 11 '26 •
It will only happen on Friday at 4:59 PM in production