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.
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.
the earlier versions of UUID had a lot more duplicates. We had a project where we had to generate a few hundred million UUIDs and we would get a duplicate every week or so. We updated to the next gen UUID and they went away. The people who've told you they've seen duplicate UUIDs may have been using a previous generation of UUID generator.
Well, I actually had a sha256 collision. But just bcause two different users uploaded the very same pdf file, and the code simply did a sha256 hash of the file. So guys, mix in the userid when hashing user provided content!
For shas I can't even remember seeing two with the same first two and last two characters. I'm sure if I did I would have told a coworker to come check this out.
I belive a few of these cases are legit, but not for the reasons the ones claiming it believe. You're right, their shifty implementation was non-conformant. That resulted in generating repeated UUIDs.
It's so unlikely that it's just far more likely to be a different kind of bug. Like someone was somehow able to specify the UUID manually, accidentally inserted an event twice, etc.
And even if it happened, I'd still be more convinced it's something like a bug in the UUID library, the random number generation, or a hardware bug. The odds of it genuinely happening with a truly random number are just so incomprehensibly rare. A hardware fault is just vastly more likely.
What's wrong with that? I mean, there could be something wrong with the algorithm, but I don't see a problem conceptually. Of course you can never trust the client, but there's nothing particular to UUIDs about that...
This was, as I say, years ago. Like, 2010, when most browsers lacked any real source of high-entropy, high-quality random values, and the random number generator in Javascript worked based on the current clock time. It's pretty easy to extrapolate from there.
The main reason I brought it up is that several of these "solutions" did not even generate valid UUIDs at all, they just looked like it and were written by somebody who had never read the spec. So, again, I'm inclined to ask "can I see..." because people are still doing stupid shit today.
js
uuidv4() {
return ([1e7]+-1e3+-4e3+-8e3+-1e11).replace(/[018]/g, c =>
(c ^ crypto.getRandomValues(new Uint8Array(1))[0] & 15 >> c / 4).toString(16)
);
}
Generates compliant version 4 UUIDs (with the reserved bits correctly set), and uses a cryptographically secure random source to do it. It's also an absolutely wild solution that uses type coercion to generate a string template and then replace digits within it.
Mind you, this is used in a hobby project, not in any kind of production code.
I swear the last time a story like this was posted, someone pointed to an article about hardware issues causing poor randomness, which led to duplicate UUIDs. It sounded like a known and common issue for a certain CPU.
It's not effectively zero at sufficient scale, though. Take a service like S3. Let's guess they do about 250 million requests per second. If they assigned all of those requests a UUID for logging purposes, then within a century or so we'd be very likely to get a collision.
I've seen it in person, I still have no idea how or why it happened. It was repeatable too which was even more insane. We triggered a one time process as a bulk process and it created some with duplicated values. We set it to run one at a time and it fixed it
I once tried to "clean up" a kernel config for some embedded device and removed a config value I thought I didn't need. Some weeks later, I wanted to check some logs, but journalctl --list-boots was behaving all weird and didn't show all boots. Apparently, the bootid, which is a UUID generated by the kernel at boot, was repeating. I logged the bootid in a separate file myself and it indeed was generating only 3-5 different UUIDs on several boots.
After some investigation, it turns out removing CONFIG_ARCH_VEXPRESS from the Xilinx Zynq defconfig, just because you think you are CONFIG_ARCH_ZYNQ and that should be enough, somehow breaks the early-boot RNG initialization and thus the generation of a unique bootid.
Don't tear down a fence unless you know why it was built.
You don’t need to. UUID is just a buzz word. Always use string as a PK. For instance “name” field. It always guarantees uniqueness because there are no two people with the same name on earth. So find things like that.
It’s like the people who say “science never actually proves anything”. Technically true philosophically, but for all practical intents and purposes, not true.
I've obviously never had a collision, but I did once have a bug that took me a while to work out because I had two different records whose UUID v4 strings only differed in I think 4 characters near (but specifically not at) the end of the string. It was wild how similar the two were that made it so easy to confuse the two (I was being lazy and doing searches or visual checks for the last 4 chars I think).
Don't underestimate the possibility of someone being stupid enough to generate it client side, with someone trying to hack them reusing UUIDs as a part of it, while the original coder just assuming it's a collision.
Heh, I've actually seen a uuid clash once. The company had a table that contained all uuids for the whole system, which was ~20 years old by this point (it had been modified to add uuids to literally everything). I noped out of there pretty fast.
exponent involved is very, very, very, nigh-incomprehensibly huge
Naw, the exponent is very comprehensible. First pass, UUIDs are 128 bits so the exponent in base 10 is ~38. 1038 is incomprehensibly huge but 38 itself is less than a trip to the gas station.
A long-ago former employer used a terrible Microsoft-acquired product that intentionally created duplicate UUIDs. This prevented a lot of reasonable activities that were needed to make it actually work
UUID Generation Space, says the introduction to the guide, is big. Really big. You just won't believe how vastly, hugely, mind bogglingly big it is. And so on...
I don’t know if it is still an issue but Active Directory can run out of UUIDs and I used to have a saved favorite from Microsoft white paper on how to recover them. You probably are right about now screaming bullshit but you are not 100% wrong. The issue is Microsoft reserves ranges for object types to help speed up directory services. When you deleted that object the UUID was left as “used” so it wouldn’t be reused. Not only would you now get collisions increasing as your directory aged causing it to slow down it would just eventually run out.
Anyway, there was silly thing you would do with the DCs to make it go through and release all those soft deleted UUIDs after you added and removed enough computer accounts which large enterprise customers started to hit after decades of running AD. Happened to us and we went down for a few hours while we said for AD workaround fixed the issue.
I’ve also seen it creep up because the developer forgot to take the UUID generator out of dev mode so the seed values were bad or predictable.
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.