UUID Version 4 Uniqueness Depends on Cryptographic Entropy
Explore why version 4 UUID collision probability depends on cryptographic entropy and how random primary keys impact B-tree index performance in databases.
A version four UUID consists of one hundred and twenty-eight bits. Six of these are fixed to denote the version and the variant, which leaves you with one hundred and twenty-two bits of randomness. This results in two to the power of one hundred and twenty-two possible unique identifiers. To put this number into perspective, it is vastly larger than the number of grains of sand on every beach on earth.
The probability of a collision is negligible for any realistic volume of data. You could generate billions of UUIDs every second for a century and still be unlikely to encounter a duplicate. This mathematical certainty provides a sense of security that allows you to ignore a central coordinating authority when assigning IDs across distributed systems. It is an elegant solution, provided the randomness is genuine.
The entropy trap
The uniqueness of a version four UUID relies entirely on the quality of the random number generator. If you use a cryptographically secure source of entropy, the collision probability remains astronomical. However, many developers rely on Math dot random in JavaScript. This function is not cryptographically secure and is often implemented as a simple linear congruential generator.
Such generators produce predictable sequences. They do not provide the true entropy required by the UUID specification. When you use a non-secure generator, you are no longer drawing from a pool of two to the power of one hundred and twenty-two options. You are instead limited by the state size of the generator itself. This significantly increases the risk of collisions, turning a mathematical impossibility into a looming production incident. It is an efficient way to ensure your database eventually breaks in a way that is difficult to debug.
To avoid this, you must use the Web Crypto API or a similar system-level source of entropy. These tools pull randomness from environmental noise, such as hardware timings, which ensures the bits are truly unpredictable.
The storage penalty
Even when you solve the randomness problem, version four UUIDs introduce a performance tax at the database level. Most relational databases use B-tree indexes to store primary keys. B-trees perform best when new data is appended to the end of the index in a sequential order.
Because version four UUIDs are entirely random, they do not arrive in any particular order. Each new insert lands in a random location within the index tree. This forces the database to frequently move existing data to make room for new entries, a process known as page splitting. As your table grows, this leads to massive index fragmentation and an increase in disk I/O. You will notice that write performance degrades as the dataset expands, simply because the database is spending more time reorganising the tree than writing the data.
If you need a unique identifier that also behaves well as a database key, you should use UUID version seven. This newer standard replaces some of the random bits with a timestamp. By placing the time at the start of the identifier, version seven ensures that IDs are lexicographically sortable. You retain the benefits of a distributed ID without the penalty of random inserts. It allows your index to grow linearly, keeping your writes fast and your disk pages tidy. It is the logical choice for anyone who values their database performance more than a strict adherence to the randomness of version four.
Try it: UUID generator
Sources
Every link below is checked before this page is published.