UUIDs explained — the uniqueness myth, the version you should be using, and the database mistake that slows everything down

UUIDs, also known as Universally Unique Identifiers, are 128-bit numbers most commonly written as 32 hexadecimal digits separated by hyphens. They offer a level of uniqueness, but it is probabilistic rather than guaranteed, with the possibility of collisions. A UUID is not a truly random string, but rather a format that includes reserved bits for versioning and layout rules.

The most commonly used version of UUID, version 4, is randomly generated and carries 122 bits of actual randomness. This level of randomness makes collisions extremely unlikely, even when generating billions of UUIDs per second continuously.

However, a version of UUID called v4 is often used as the default primary key in databases due to its simplicity. Yet, there are issues with using random UUIDs as primary keys in databases. When new rows are inserted with random keys, the database must place them at random locations within the index, leading to performance issues.

This behavior causes page splits, poor cache locality, and index bloat, which can significantly slow down database operations. While version 4 UUIDs were initially a straightforward solution, this common choice has become problematic when scaling databases, leading to a reconsideration of UUID usage in database primary keys.