What a v4 UUID is
A version 4 UUID is 122 random bits plus 6 fixed bits that identify the version and variant, formatted as 32 hexadecimal digits in five hyphen-separated groups. Those 122 bits give around 5.3 × 10³⁶ possible values.
The practical consequence is that two independent systems can generate UUIDs forever without coordinating and never collide. You would need to produce a billion UUIDs per second for about 85 years to reach a one-in-a-billion chance of a single duplicate.
Why the random source still matters
UUIDs routinely end up as session identifiers, password-reset tokens and unguessable object keys. Uniqueness alone is not enough for those jobs — they must also be unpredictable. A UUID generated from a non-cryptographic PRNG is unique and guessable, which is the worst combination. This tool uses crypto.randomUUID, falling back to crypto.getRandomValues, never Math.random.
UUIDs make poor primary keys
v4 UUIDs are random, so inserting them into a clustered index writes to random points in the B-tree rather than appending. On a large table that fragments the index and hurts insert throughput noticeably.
If you want both global uniqueness and insert locality, look at UUIDv7 or ULID — both put a timestamp in the high bits so values sort roughly by creation time while staying unique.