Skip to main content
riqo.ioTools for big ideas

UUID: unique identifiers, versions and uses

UUID structure, variants and versions, collision probability and design choices for distributed identifiers.

What a UUID is

A UUID is a 128-bit identifier designed to be generated without a central allocator. The canonical textual form uses 32 hexadecimal digits grouped with hyphens, while the fundamental value remains 128 bits.

Uniqueness is not an absolute mathematical property of every UUID. It depends on the generation algorithm and domain; the practical goal is to make collisions negligible or avoid them through a version-defined structure.

Variant and version fields

Specific bits identify the variant and version, defining a layout family and how the remaining bits were generated. A string can therefore be syntactically valid while still being the wrong UUID version for a protocol.

Validation should distinguish textual format, variant, version and application policy. Merely parsing a UUID does not prove that it is appropriate for the surrounding contract.

UUID v4 and randomness

UUID v4 allocates most bits to randomness while reserving bits for version and variant. With a cryptographically strong random generator, the address space is enormous and collisions are extremely unlikely at ordinary scales.

Collision probability grows with the number generated according to the birthday bound, but a faulty RNG or non-conforming implementation is often a more realistic operational risk than exhausting the theoretical space.

Time-oriented versions and UUID v7

Other versions incorporate time, namespaces or hashes. UUID v7 places a Unix-millisecond timestamp in the most significant area and combines it with random bits, producing identifiers with useful temporal ordering.

Time-sortable identifiers can improve index locality in some databases, but they expose timing information and do not replace business ordering. Choose a version from requirements rather than trend.

Databases, APIs and trust boundaries

UUIDs work well as public keys because they avoid a global sequence and are less predictable than incrementing integers. They can, however, cost more than compact integers in indexes, caches and textual payloads.

A UUID is not an authorization token. Possessing an identifier must never grant access by itself; authentication and permission checks remain independent security controls.

Best practices

Use native UUID or binary storage where available, normalize textual forms at boundaries and validate the expected version when a contract requires it. Never build UUIDs from ad-hoc weak random generators.

Define whether an identifier is stable, public, reusable and meaningful across environments. Identifier choice is part of the data model and deserves an explicit policy.

Related guides

UUID v1, v4 and v7: generation, ordering, collisions and ID design

Comparing UUID versions and choosing between random, time-based and time-sortable identifiers.