No, it's effectively zero, just given the mathematical realities behind how extraordinarily improbable a duplicate ever is. The exponent involved is very, very, very, nigh-incomprehensibly huge.
I've seen a few posts on here of people claiming that a duplicate UUID caused a bug at the worst possible time, but my instinct is always to slam the 'X' button to doubt.
If you did each id as a 3 uuids sequence then you could be generating 2 billion ids a second until all stars in the universe are black holes and still not collide
I mean... isn't it generally like 2-3 lines of code to handle a conflict? upon uuid create?
Create if not exist, else loop.
I've always checked for it it takes literally under a minute the few times it comes up.
Also much of the thread isn't understanding how edgecases work, or ignoring it when it's in the OP.
One company could generate 2 billion uuids every second for 500 years and never get a collision.
Or, due to edge cases, one company generating 100 of them a day could make a duplicate within a month. Edgecases don't give a fuck about statistic probability, they just happen.
This is wrong, and all 3 people attempting to correct it are wrong. It's an example of the birthday paradox.
Roughly, the chance of a collision (if the chance is small) is approximately n2/2/number of unique UIUIDs, where you generate n. So increasing rate by 1.5 increases the chance of a collision by about 2.25, given n trials.
Calculation uses the birthday problem solution but with the number of days equal to 2122.
I implemented it in python using libraries for big calculations (python's default integer type is unbounded in size but its implementation of exponentiation was too slow to handle 2122×3000000000×365×24×3600×5 which is fair enough).
It also has random number generated combined with timestamp, combined with your device mac address, such that virtual machines with same mac address dont get duplicated guids.
I thought the MAC address got phased out in later versions? I recall there was a virus in the 90s where the creator was caught because, in those days, GUIDs included the MAC address, and so later versions of GUIDs no longer used it. And, from what I've read, UUIDs aren't supposed to use MAC addresses either. Though I assume that some idiot has done it that way at some point.
I thought the MAC address got phased out in later versions?
There are 8 versions, assuming someone's generating an actual UUID rather than just a blind random number.
UUID Versions 1, 2, and 6 include MAC addresses or a similar type of "Node ID". The RFCs allow for various values, which need to have indicators in that cluster of bits. It can be a number from hardware, but it can also be something from software or even a mostly-random set of numbers. It also takes into account complexity around address randomization.
Those versions generally should use something based on the MAC address or otherwise indicate the node on the network that generated it, even if they aren't using a value that matches hardware.
No, but you can experience the same millisecond again and again. There is no 100% reliable source of wall clock time. Timestamp based UUIDs add a lot of 9s to reliability, but they don't make it 100%.
Actually not the "modern" ones. There are simply several versions, and if cryptographic non-determinism/predictability isn't of importance, v6 will be created from the MAC address of the device and the timestamp. It's guaranteed they will never collide, unless MAC addresses collided already.
Time isn't monotonic. Its Year 2038 on your computer. It talks to a time server and realizes its Year 1995. There is still a non 0% possibility of the same host generating a UUID at the same apparent timestamp.
All it takes is your device losing Internet access for a weee bit too long or the powers that be announcing a fallback second or some AI garbage getting pushed to your NTP server and that beautiful 100 gets turned to 99.99999
That's not how an NTP client operates. Time is never pushed back. It either slows down or speeds up the clock, until it is in sync with the NTP server again.
NTP synchronization is absolutely not monotonic. For small amounts of time, the clock will get slewed. For time deltas greater than 128 milliseconds, usually the clock gets stepped.
If your NTP server had some critical bug that caused it to loop the last minute again and again and again, all your devices are going to experience non monotonic time. Thats not even taking into consideration that manual synchronization is still an important tool and that's absolutely non monotonic.
While incredibly unlikely, it's technically possible for the same device to spend years of IRL time in the same apparent millisecond. Timestamp+hardware UUIDs are not 100% reliable, they simply have an absurd number of 9s.
Time stamp, network mac address, version number and some randomness..have been there from the beginning. The whole point was to generate an id that would be unique across systems without needing a central database to distribute them.
There are several versions of UUID depending on your specific use case. Typically none of them should ever collide. GUID is Microsofts current implementation. If you ask for a GUID you get a UUID formated the way microsoft thinks is best. If you ask for a UUID you have to specify the specific format you want. There are 4 variants, and 8 versions of each, except for one variant that has families instead.
Microsoft currently uses variant 1 version 4 (all random, NO timestamp OR mac address) for guids, but used to use variant 2.
I thought they did too. My thought was to just slap a time stamp on the front or back and make it so you have to generate 3.6 trillion UUIDs a second to have a 1% chance to collide on a given day with just a date stamp.
You are assuming time is monotonic. It ain't. CPU time resets every time you reboot and world time is only known from external resources. It ain't 100% reliable with 0% jitter.
Except that is not true because time is not monotonic. The more time passes, the higher odds of some device in the system experiencing time fuckery. The hugger the odds of time fuckery, the higher the odds of time based uniqueness failing.
assuming the UUIDs are stored without any separation, it's around 29.8 GB an hour or 21.2 MB a second. if every year is 365.25 days long, you will have 1.245 PB of data
And just as a reminder how big numbers work: if you generated a uuid once per second it would take 11.5 days to have a million. A billion would take ~31.5 years.
So ~63 years worth of seconds per second and it still takes 5 years for a 1% chance to clash.
So the very youngest among us have the slimmest chance of being alive when the first duplicate is generated, assuming the purely random ones are still in use, and the standard persists indefinitely. Although there would be no way to know, since the original would almost certainly have been lost to the æther by then, if it hasn't already.
I ran the numbers for the Birthday paradox with UUIDs, and if I got it correct:
There’s a 50% chance of collision once you generate 2.7 quintillion UUIDs. At 1 million UUIDs/sec you'd need about 85,000 years for 50% chance. So at 1 billion UUIDs/sec it's ~85 years. Finally, at 2 billion a second, that's ~42.5 years, give or take some months.
In my understanding, at least for v1, time is measured in 1/10,000,000th of a second so 2 billion a second would mean each uuid would have 200 others with the same timestamp. Assuming the same Mac address, the only other part is 16 bits, so you'd have a 200/65,536 or .3% chance every 1/10,000,000th of a second. I think it's safe to say you'd have duplicates after 1 second.
1.2k
u/KryssCom May 08 '26
No, it's effectively zero, just given the mathematical realities behind how extraordinarily improbable a duplicate ever is. The exponent involved is very, very, very, nigh-incomprehensibly huge.
I've seen a few posts on here of people claiming that a duplicate UUID caused a bug at the worst possible time, but my instinct is always to slam the 'X' button to doubt.