Which UUID version should I choose?
Version 4 for most tasks: it is made of random bits and reveals nothing about where or when it was created. Choose version 7 when rows have to sort by insertion time. Versions 3 and 5 are for identifiers derived from a name, so that the same input always gives the same value; version 6 is for systems that already hold version 1 identifiers, and versions 1 and 2 remain for compatibility with older systems.
Can a version 4 UUID be used as a secret token?
For single-use links, with reservations; for passwords and access keys, no. Guessing 122 random bits is out of reach, but identifiers are treated as non-secret by convention: they end up in server logs, the address bar and the Referer header. Issue a separate token for access and leave the UUID as an identifier.
Can two generated UUIDs be identical?
In theory yes, in practice no. Version 4 has 122 random bits, which gives roughly 5.3 × 10^36 possible values, so a collision stays negligibly unlikely even across billions of identifiers. In the versions where part of the bits holds a timestamp, uniqueness comes from combining that timestamp with a random part or a node address.
Why does version 4 sit poorly in a database index?
Every new value lands in a random spot of the index, so inserts scatter across the tree and pages have to be loaded and split more often. On large tables this shows. If insertion order matters, take version 7: it starts with a timestamp and grows from one end.
Do the identifiers follow the standard?
Yes. Identifiers of every version follow the format from RFC 4122 (updated by RFC 9562): 32 hexadecimal digits split by hyphens into 8-4-4-4-12 groups, with the version number and the variant in their designated positions. The random bits come from a cryptographically secure source of randomness.