UUID Standard: From UUIDv1 to UUIDv8 – A Complete Guide

UUID — a 128-bit string you see everywhere, from REST APIs to database primary keys — is not just one thing. It is a family of eight distinct versions, each with radically different trade-offs for privacy, sortability, and database performance. Choosing the wrong version can silently fragment every B-tree index in your production database. This guide explains them all.

1. Introduction

A Universally Unique Identifier (UUID) is a 128-bit standard for uniquely identifying information in computer systems. In the design of modern distributed systems, microservice architectures, and multi-instance databases, generating unambiguous identifiers without consulting a central registry is a fundamental performance and reliability requirement.

In the era of monolithic applications backed by a single relational database, sequential integer counters (AUTO_INCREMENT or SERIAL) served as primary keys. As systems scaled horizontally, this approach became obsolete. A centralized ID generator is a Single Point of Failure and introduces a network round-trip on every write. UUID was created to allow independent nodes to generate unique identifiers in a decentralized manner with zero or negligible probability of collision.

In engineering practice the term GUID (Globally Unique Identifier), used mainly in the Microsoft ecosystem, is also frequently encountered. Structurally, UUID and GUID are conceptually identical — both represent 128-bit binary values. The difference comes down to history and implementation-level specifications. While the RFC defines data storage in network byte order (Big-Endian), Microsoft COM and older .NET implementations use Little-Endian internally for selected fields. This difference is significant when sorting and binary-indexing in relational database engines.

2. Standards and Specification Evolution

The standardization of unique identifiers evolved over four decades through several key milestones. Apollo NCS (late 1980s) introduced the Variant 0 concept. The Open Software Foundation (OSF) incorporated UUIDs into the Distributed Computing Environment (DCE) spec, formally splitting the 128-bit structure into time and hardware fields. RFC 4122 (2005) was the main industry standard for nearly two decades, defining versions v1–v5. RFC 9562 (May 2024) is the current IETF standard that obsoletes RFC 4122, officially standardizing UUIDv6, UUIDv7, and UUIDv8 in direct response to the B-tree performance problems caused by random UUIDs.

Every UUID contains two key control fields. The Variant field (bits 64–65 for RFC 9562 Variant 1) defines the general interpretation of the remaining bits — the most popular Variant 1 is marked by setting the first two bits of byte 8 to binary 10. The Version field is a 4-bit code at bits 48–51 that identifies the specific algorithm used to generate the identifier (values 0x1 through 0x8).

3. The 128-Bit Structure

The canonical text format consists of 32 hexadecimal digits arranged in five groups separated by hyphens in the layout 8-4-4-4-12, giving 36 ASCII characters total: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where M is the 4-bit version and N contains 1–3 variant bits. In the hexadecimal representation the N position always starts with one of: 8, 9, a, or b.

4. History of UUID and the Birth of RFC 9562

RFC 4122 promoted UUIDv4 as the universal identifier. Although UUIDv4 provides excellent uniqueness through 122 bits of randomness, its completely disordered structure causes performance degradation when writing to relational databases. Inserts of completely random identifiers lead to B-tree fragmentation, frequent page split operations, and a drastic drop in cache locality. UUIDv1 had a timestamp component but arranged the time bits in the wrong order (least-significant bits first), making chronological sorting impossible, while also creating serious privacy risks by exposing the MAC address of the network interface.

5. All UUID Versions (v1 – v8)

UUIDv1 — Time-based + MAC Address

UUIDv1 is based on a 60-bit timestamp measured in 100-nanosecond intervals since 15 October 1582 (the Gregorian calendar reform), a 14-bit clock sequence, and a 48-bit MAC address. The critical design flaw: the most significant time bits land at positions 52–63 while positions 0–31 hold the least significant time_low bits. This layout makes chronological sorting of the text or binary string impossible.

UUIDv2 — DCE Security

UUIDv2 is reserved for the OSF DCE Security specification. It replaces the first 32 bits of the time_low field with a local security identifier (POSIX UID or GID), and part of the clock sequence field encodes the security domain. This version is rarely used in modern engineering practice. Its reduced space for the timestamp and clock sequence means uniqueness is only guaranteed within short time windows — approximately 7 minutes per UID/GID per node.

UUIDv3 — Name-based MD5

UUIDv3 is a deterministic identifier. It is produced by computing the MD5 hash of a combination of a namespace UUID (in binary form) and a resource name string. The appropriate Variant (10) and Version (0011) bits are set in the resulting 128-bit value. The same namespace + name input always produces the same UUID. Due to known MD5 collision vulnerabilities, RFC 9562 recommends UUIDv5 (SHA-1) over UUIDv3 in every deterministic scenario.

UUIDv4 — Random

UUIDv4 is based entirely on random numbers. Of the 128 bits, 6 are reserved for the version (0100) and variant (10) bits, leaving exactly 122 bits of pure entropy. Generation must rely on a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). The probability of collision at 50% would require generating approximately 2.71 × 10¹⁸ identifiers. Generating a billion IDs per second for a hundred years still yields a collision probability of roughly 10⁻⁹. UUIDv4 became the most popular version due to its simplicity — it requires no knowledge of system time, clock state, or MAC address.

UUIDv5 — Name-based SHA-1

UUIDv5 works analogously to UUIDv3 but uses the SHA-1 cryptographic algorithm instead of MD5. From the 160-bit SHA-1 output, the first 128 bits are taken, the version bits are overwritten with 0101, and the variant bits with 10. Because of MD5's vulnerability to collisions, RFC 9562 recommends choosing UUIDv5 in every scenario that requires identifiers deterministically generated from names.

UUIDv6 — Reordered Time-based

UUIDv6 is a direct modification of UUIDv1 designed to provide lexical sortability in databases while maintaining structural compatibility with v1. The 60-bit Gregorian timestamp bits are rearranged so that the most significant bits come first: bits 0–32 hold time_high (most significant), bits 33–48 hold time_mid, bits 49–52 hold the version (0110), and bits 53–64 hold time_low (least significant). This bit reordering enables lexical and binary sorting and reduces B-tree fragmentation, but since it still uses Gregorian timestamps and MAC addresses it is considered a transitional version for systems migrating from UUIDv1.

UUIDv7 — Unix Epoch Time-based (Recommended)

UUIDv7 is the solution recommended by RFC 9562 for all new systems and databases. It combines a 48-bit Unix Epoch timestamp (milliseconds since 1 January 1970) with 74 bits of random entropy.

UUIDv8 — Custom

UUIDv8 provides a flexible format for custom solutions. It only mandates the 4 version bits (1000) and the 2 variant bits (10). The remaining 122 bits can be used freely by software architects. It is used in scenarios requiring domain-specific data embedded in the identifier — such as a tenant ID, custom nanosecond timestamp precision, or geolocation coordinates. UUIDv8 has no universal semantics and requires a custom parser at the application layer.

6. Comparison of All UUID Versions

7. Database Performance Comparison

Using completely random UUIDv4 as a primary key causes performance problems in relational database engines. Most databases use B-tree indexing for primary keys. Data is stored on pages (typically 8 KB or 16 KB). When inserting random identifiers (UUIDv4), the database must insert new records into random positions in the tree. When the target page is full, the engine performs a page split — creates a new page and moves 50% of data to it. With UUIDv4 this results in thousands of page split operations per million inserts, whereas for sequential IDs the number is negligible.

• Index Fragmentation: Frequent page splits leave B-tree pages only 60–70% full, causing index bloat and doubling disk usage.
• Cache Locality: Inserting entirely random keys invalidates pages in the RAM buffer pool, forcing the database to constantly perform physical disk I/O.
• PostgreSQL 18: Introduces native uuidv7() function. Benchmarks show a 35–50% reduction in index size and faster writes at scale compared to UUIDv4. PostgreSQL also provides uuid_extract_timestamp() and uuid_extract_version() helper functions.
• MySQL (InnoDB): Enforces a Clustered Index, meaning entire table rows are physically arranged on disk by primary key order. Using UUIDv4 in MySQL causes entire rows to be moved during page splits, producing high IOPS overhead.
• SQL Server: The uniqueidentifier type uses an atypical binary sort order (bytes 10–15 first, then 8–9, etc.). Generating standard UUIDv7 without proper byte reordering in .NET will cause the same fragmentation in SQL Server as UUIDv4.
• Oracle: Stores UUID in RAW(16). Without sortability, requires regular ALTER INDEX REBUILD maintenance operations.

8. UUID and Databases: Migration

Choosing a primary key type involves architectural trade-offs between size, uniqueness, and performance. AUTO_INCREMENT (BIGINT) offers the smallest footprint (8 bytes) and excellent performance but reveals database size (enumeration attack) and prevents generating IDs outside the database. Classic UUIDv4 guarantees distribution but destroys B-tree indexes. UUIDv7 mitigates these drawbacks by combining sequential write performance with distributed generation without conflicts.

Migrating from UUIDv4 to UUIDv7 does not require changing the column type, since both versions are represented by the same 128-bit UUID or BINARY(16) type. The migration steps are: (1) swap ID generators in application code from v4 to v7; (2) the database gradually begins placing new rows on the right edge of the B-tree; (3) rebuild old indexes (e.g., REINDEX TABLE in PostgreSQL or OPTIMIZE TABLE in MySQL) to compact previously fragmented pages.

9. UUID vs ULID vs KSUID vs Snowflake

Since the publication of RFC 9562, ULID is no longer a clear winner over UUID. ULID and UUIDv7 offer comparable technical parameters (48-bit millisecond timestamp plus entropy). The advantage of UUIDv7 is official IETF standardization and native support in databases and programming languages. Snowflake IDs offer the best B-tree performance and smallest binary size (8 bytes) but require coordinated node ID assignment, making them unsuitable for fully decentralized systems.

10. Historical UUID Problems

• MAC Address Exposure: Early software (e.g., Windows COM objects) used UUIDv1 for document identification, allowing digital files to be traced back to the physical computer of their creator.
• Insufficient Entropy and Predictable RNG: Using weak pseudo-random number generators (e.g., rand() in C or Math.random() in JavaScript) led to security vulnerabilities. In several systems, generated UUIDv4 values overlapped, enabling session hijacking.
• .NET 9 and Guid.CreateVersion7(): The new function preserves the internal Little-Endian Guid format. Without explicit bigEndian: true conversion when writing to PostgreSQL, index sizes grow over 35% compared to correct Big-Endian binary form.
• Atypical Sorting in MS SQL Server: Storing UUIDv7 in a uniqueidentifier column without proper byte permutation causes B-tree fragmentation because SQL Server sorts this type starting from the last bytes.

11. Common Misconceptions

• "UUID guarantees 100% uniqueness" — Uniqueness for random versions is a probabilistic property. The mathematical collision risk exists, though with a proper CSPRNG it is astronomically small.
• "Every UUID is random" — Only v4 consists almost entirely of random bits. Versions v1, v6, and v7 contain precise timestamps; v3 and v5 are deterministic cryptographic hashes.
• "UUID is faster than Integer" — Comparing 128-bit fields in databases requires more CPU cycles than operating on 64-bit integers.
• "UUID cannot collide" — Incorrect clock configuration, lack of access to a strong entropy source, or faulty monotonic counters can produce duplicates.
• "UUID always has 36 characters" — The 36-character representation is only the text presentation form. At the disk layer, databases store UUID as pure 16 bytes.

12. Implementation in Programming Languages

The following libraries provide RFC 9562-compliant UUIDv7 generation. In Java, the uuid-creator library (by Fabio Lima) is the recommended choice, providing both Guid.getUuidV7() for standard generation and a non-cryptographic fast variant for extreme throughput scenarios. In .NET 9+, Guid.CreateVersion7() is built into the runtime — always use .ToByteArray(bigEndian: true) when extracting bytes for PostgreSQL. In Python, the uuid6 module covers v6, v7, and v8; Python's standard library uuid module covers only v1, v3, v4, and v5. In Go, the google/uuid package provides uuid.NewV7(). In Rust, the uuid crate supports v7 with the "v7" feature flag. In Node.js/TypeScript, the uuid npm package (v11.0.0+) exports v7 as uuidv7.

13. Library Comparison

14. Performance Benchmarks

The performance advantage of UUIDv7 stems from the fact that reading a 48-bit timestamp register is a CPU operation that does not require invoking the full CSPRNG entropy block for the entire bit string — only the 74 random bits need a CSPRNG call. The non-cryptographic fast variant foregoes CSPRNG entirely for the random fields, using an atomic monotonic counter instead, which is safe only when the timestamp already provides uniqueness guarantees.

15. Decision Matrix

16. Best Engineering Practices

• Adopt UUIDv7 as the default in new projects — the recommended choice for resource identifiers, primary keys, and event log entries.
• Always use a CSPRNG source — ensure cryptographically secure entropy is available in the runtime environment.
• Never use UUID as an authorization mechanism — UUID is for identification, not authentication. Knowing a UUID must not represent an access permission.
• Store UUID in native binary types — use the native uuid type in PostgreSQL or BINARY(16) in MySQL. Avoid VARCHAR(36) text format.
• Avoid UUIDv1 and UUIDv2 in new systems — their outdated design and potential MAC data leaks disqualify them.
• Use UUIDv5 for deterministic IDs — when you need to compute a stable identifier from a name string, always prefer UUIDv5 (SHA-1) over UUIDv3 (MD5).

17. Frequently Asked Questions

Is UUID truly unique?

For software engineering purposes — yes. Uniqueness of random versions (v4, v7) relies on mathematical probability. The probability of generating a duplicate when using a proper entropy source is so small that it is considered zero in practice.

Can UUID repeat?

It can only repeat in the case of a runtime environment failure: damaged random number generator, no CSPRNG access, system clock reset without monotonic counters, or a faulty multithreaded library implementation.

Will UUIDv7 replace UUIDv4?

UUIDv7 is progressively displacing UUIDv4 in all database and state-storage applications. UUIDv4 will remain in use in areas where the creation time of the identifier must deliberately be hidden.

Why does the canonical UUID form have 36 characters?

The 128-bit structure maps to 32 hexadecimal digits. Separating them with 4 hyphens in the standard 8-4-4-4-12 format gives a total length of 36 ASCII characters.

Is ULID better than UUID?

No, not since RFC 9562 was published. ULID and UUIDv7 offer comparable technical parameters. The advantage of UUIDv7 is official IETF standardization and native support in databases and programming language runtimes.

When should numeric IDs be used instead of UUID?

Numeric identifiers (e.g., BIGINT) remain the better choice in closed, single-instance databases with very high load, where index size is critical, data is not exposed externally through APIs, and there is no need to generate keys on independent distributed nodes.