UUID Versions and Which to Use
A UUID is a 128-bit identifier written as 32 hexadecimal characters in five hyphen-separated groups. Several versions exist, and they solve different problems.
Version 4 — random (what this tool generates)
122 random bits, with 6 bits fixed to mark the version and variant. It carries no information about where or when it was made, which is exactly why it is the default choice for most applications.
Version 1 — timestamp and MAC address
Encodes the generating machine’s network address and the time of creation. Sortable, but it leaks hardware identity and creation time — a genuine privacy concern if the identifier is ever exposed publicly.
Version 7 — time-ordered
A newer format that puts a millisecond timestamp in the leading bits followed by random data. It sorts chronologically without exposing hardware, which makes it increasingly the preferred choice for database primary keys.
Can Two UUIDs Ever Collide?
In principle yes; in practice no. With 122 random bits there are roughly 5.3 × 1036 possible version 4 UUIDs. To reach a 50% chance of a single collision you would need to generate about 2.7 × 1018 of them — 2.7 quintillion.
Put concretely: generating a billion UUIDs every second, it would take around 85 years to reach a 50% chance of one duplicate anywhere in the set. For any real application the risk is negligible, provided the generator uses a cryptographically secure random source. That last condition is the one that actually matters — collisions in the wild come from weak randomness, not from exhausting the address space.
Using UUIDs as Database Keys
UUIDs remove two real problems with auto-incrementing integers. They can be generated by any client without asking the database first, which matters for distributed systems and offline-capable applications. And they do not leak business information — an order numbered 1,247 tells a competitor roughly how many orders you have taken; a UUID tells them nothing.
The trade-off is index performance. Random version 4 values scatter inserts across the whole B-tree index rather than appending at the end, which fragments pages and slows writes on large tables. They also occupy 16 bytes against 4 or 8 for an integer, multiplied across every foreign key that references them. If you are choosing keys for a table that will grow large, this is precisely why version 7 — time-ordered, so inserts stay sequential — is now usually the better answer than version 4.