UUID Specification Matrix: RFC 4122 vs. RFC 9562
The Internet Engineering Task Force (IETF) ratified RFC 9562 in 2024 to modernize the foundational RFC 4122 standard. Selecting the appropriate UUID version depends on data clustering requirements, cryptographic entropy needs, and security constraints:
| Version | Standard | Generation Mechanism | Time Sortable | Primary Use Case |
|---|---|---|---|---|
| UUID v4 | RFC 4122 | Cryptographic Pseudo-Random (CSPRNG) | No (Uniformly Random) | General-purpose unique IDs, session tokens, API keys, distributed tracing (Standard Default) |
| UUID v7 | RFC 9562 (2024) | 48-bit Unix Epoch ms + 74-bit Random | Yes (Monotonic / Big-Endian) | Relational database primary keys (PostgreSQL, MySQL InnoDB, SQLite), clustered B-Tree indexes |
| UUID v1 | RFC 4122 | 60-bit Gregorian Timestamp + 48-bit Node ID (Random / MAC) | Non-standard (Time-low first) | Legacy enterprise systems; web generator uses random node bits per RFC 4122 §4.5 to protect privacy |
| UUID v3 / v5 | RFC 4122 | MD5 (v3) / SHA-1 (v5) Namespace Hash | No | Deterministic IDs derived from fixed namespace and name string (e.g. URI, DNS mapping) |
| UUID v6 | RFC 9562 | Reordered v1 60-bit Gregorian Timestamp | Yes (Monotonic) | Drop-in replacement for legacy v1 systems requiring chronological B-Tree sorting |
| UUID v8 | RFC 9562 | Custom / Vendor-Defined Bit Layout | Implementation-specific | Custom enterprise architectures requiring non-standard embedded bit payloads within a 128-bit UUID container |
| Nil / Max UUID | RFC 4122 / 9562 | All 128 bits set to 0x00 (Nil) or 0xFF (Max) | Bounding limits | Sentinel values, uninitialized defaults (00000000-0000-0000-0000-000000000000), and range query boundaries |
128-Bit Layout & Binary Structure
A standard UUID consists of exactly 128 bits (16 octets / 32 hexadecimal characters) arranged into five hyphenated groups: 8-4-4-4-12. In standard network byte order (big-endian), specific bit positions indicate the version number and RFC variant:
UUID v4 (Random)
RFC 4122 §4.4- xxxxxxxx-xxxx: 48 bits of pseudorandom data.
- 4xxx: 4-bit Version (
0100₂ = 4) followed by 12 bits of pseudorandom data. - yxxx: 2-bit Variant (
10₂; hex character 8, 9, a, or b) followed by 14 bits of pseudorandom data. - xxxxxxxxxxxx: 48 trailing bits of pseudorandom data. Total entropy: 122 bits.
UUID v7 (Epoch Milliseconds)
RFC 9562 §5.7- tttttttt-tttt: 48-bit unsigned Unix epoch timestamp in milliseconds (big-endian).
- 7xxx: 4-bit Version (
0111₂ = 7) followed by 12 bits of random data or monotonic counter. - yxxx: 2-bit Variant (
10₂) followed by 14 bits of random data. - xxxxxxxxxxxx: 48 trailing bits of random data. Total random entropy: 74 bits.
Data1, Data2, Data3) in native x86 little-endian format. While textual representation is identical, binary conversions between COM GUIDs and standard RFC UUIDs must account for this endianness transposition.Database Performance: Why UUIDv7 Solves the Clustered B-Tree Problem
In relational database engines like PostgreSQL, MySQL (InnoDB), and SQLite, primary keys dictate the physical order of clustered B-Tree index pages on disk. The generation pattern of your primary keys directly affects write throughput and storage efficiency:
The Random UUIDv4 Write Penalty
Because UUIDv4 values are uniformly random, each record insertion targets an unpredictable page in the B-Tree index. As datasets outgrow available RAM, the database engine must repeatedly read random index pages from disk, split saturated pages into two half-empty pages, and rewrite parent nodes. This causes:
- Severe write amplification and random disk I/O thrashing
- 50% index fill factor bloat due to ongoing node splitting
- Eviction of critical query cache pages from the database buffer pool
The Sequential UUIDv7 Solution
UUIDv7 prefixes each identifier with a 48-bit millisecond timestamp. This guarantees that new records naturally append to the rightmost leaf of the clustered B-Tree index, functioning like traditional auto-increment integers:
- Zero mid-tree page splits on sequential high-volume ingestion
- Optimal index page filling (approaching 90–100% packing density)
- Decentralized generation across microservices without central locks
| Storage Strategy | Disk Size Per Row | Index Footprint (10M Rows) | Insert Locality |
|---|---|---|---|
| UUIDv4 in VARCHAR(36) | 37 bytes (36 + 1 prefix) | ~750 MB (due to 50% fill splits) | Completely random |
| UUIDv4 in BINARY(16) / uuid | 16 bytes | ~320 MB | Random |
| UUIDv7 in BINARY(16) / uuid | 16 bytes | ~175 MB (compact packing) | Monotonic append |
Collision Probability & Cryptographic Entropy Bounds
In distributed systems, collision likelihood is evaluated using the Birthday Problem approximation: p ≈ 1 - exp(-n² / (2 × 2^k)), where k represents the number of random entropy bits and n represents the count of generated identifiers.
UUID v4 Entropy Bounds
UUID v4 contains 122 bits of cryptographic randomness (2¹²² ≈ 5.3 × 10³⁶ possible values).
- To incur a 1-in-a-billion (
10⁻⁹) chance of a single collision, a system must generate 103 trillion UUIDs. - Generating 1 billion UUIDs per second for 100 consecutive years yields a collision probability of less than
10⁻¹⁵.
UUID v7 Concurrency Bounds
UUID v7 contains 74 bits of entropy combined with millisecond resolution.
- Within each single millisecond window, 2⁷⁴ (≈ 1.88 × 10²²) unique values are possible.
- Even with 10,000 independent nodes generating identifiers simultaneously in the exact same millisecond, the collision risk remains mathematically zero.
- Monotonic counters defined in RFC 9562 §6.2 guarantee strict ordering for multiple IDs issued within the same tick.
UUID Generation Across Programming Languages
Standard library and production-grade implementations for modern backend runtimes and databases:
// Native RFC 4122 UUID v4 (Browser & Node 14.17+):
const v4 = crypto.randomUUID();
// RFC 9562 UUID v7 (via 'uuid' package):
import { v7 as uuidv7 } from 'uuid';
const v7 = uuidv7();Identifier Systems Compared: UUID vs. ULID vs. NanoID vs. TSID
Engineers select identifier schemes based on database indexing characteristics, character set length, and formal standardization:
| Identifier | Bit Size | String Length | Sortable | Standardization | Best Fit |
|---|---|---|---|---|---|
| UUID v4 | 128 bits | 36 chars | No | IETF RFC 4122 | Ephemeral tokens, non-clustered IDs |
| UUID v7 | 128 bits | 36 chars | Yes (ms) | IETF RFC 9562 | Relational database clustered PKs |
| ULID | 128 bits | 26 chars (Base32) | Yes (ms) | Community spec | Compact URL slugs requiring time order |
| NanoID | Configurable | 21 chars (Base64) | No | NPM library | Short public-facing URL identifiers |
| TSID / Snowflake | 64 bits | 13 chars / BIGINT | Yes (ms) | Custom / Twitter | Native 64-bit integer columns |
Frequently Asked Questions
Which UUID version should I choose: UUID v4 or UUID v7?
Choose UUID v7 for relational database primary keys (PostgreSQL, MySQL, SQLite) or any dataset indexed with B-Trees, because its 48-bit millisecond timestamp prefix prevents index fragmentation. Choose UUID v4 for general-purpose unique identifiers, API tokens, session IDs, and distributed tracing where chronological ordering is not required or could leak record creation timing.
What is the practical risk of a UUID collision in production?
Practically zero. UUID v4 contains 122 bits of cryptographic randomness (2¹²² ≈ 5.3 × 10³⁶ possible values). By the Birthday Problem, generating 103 trillion UUIDs carries only a 1-in-a-billion chance of a single collision. UUID v7 combines a 48-bit millisecond timestamp with 74 bits of entropy (2⁷⁴ ≈ 1.88 × 10²² values per millisecond), ensuring collision-free operation even across high-concurrency distributed clusters.
Why is UUID v7 superior to UUID v4 for database primary keys?
Random UUID v4 values scatter writes across arbitrary B-Tree index pages, causing frequent leaf splits, 50% index fragmentation, and massive random disk I/O once the table exceeds RAM. UUID v7 prefixes each identifier with a chronological timestamp, guaranteeing that new records append sequentially to the rightmost leaf of the clustered index, achieving the write performance of auto-increment integers with the benefits of decentralized ID generation.
What is the difference between a UUID and a Microsoft GUID?
UUID (Universally Unique Identifier) and GUID (Globally Unique Identifier) refer to the same 128-bit mathematical concept. UUID is the formal IETF standard (RFC 4122 / RFC 9562). GUID is Microsoft's historic Windows implementation. Textually, both use the same hyphenated 8-4-4-4-12 hex representation and are interchangeable. Internally, early Windows GUIDs used little-endian byte ordering for the first three components, whereas standard RFC UUIDs use big-endian network byte order.
How should UUIDs be stored in PostgreSQL, MySQL, and SQLite for maximum performance?
In PostgreSQL, store UUIDs using the native 16-byte "uuid" type, which indexes natively in B-Trees. In MySQL 8+, use "BINARY(16)" instead of "VARCHAR(36)" to cut index footprint by 55%, using UUID_TO_BIN() or native UUID v7. In SQLite, use 16-byte "BLOB" or 32-character "TEXT" columns. Pairing binary storage with time-ordered UUID v7 minimizes disk footprint and eliminates B-Tree node rebalancing overhead.
How do I validate an existing UUID and extract its creation timestamp?
Switch to the "Validator & Inspector" tab above and paste your UUID string. The tool checks RFC 4122 / RFC 9562 syntax compliance, detects the version number (e.g. v1, v4, v7) and variant bits, and automatically extracts the embedded UTC date and time for time-based versions (UUID v7 and UUID v1).
Why is UUID v1 discouraged in modern web applications, and does this browser tool access my MAC address?
Under the original RFC 4122 specification, server-side UUID v1 implementations embed the host machine's 48-bit physical IEEE 802 MAC address and a 60-bit Gregorian timestamp, which could expose underlying physical network identities in public APIs. In web browsers, JavaScript has no access to your physical MAC address due to security sandboxing. As specified by RFC 4122 §4.5 for systems without MAC access, this tool generates a cryptographically secure pseudo-random 48-bit node with the multicast bit set, ensuring zero hardware identification leakage while maintaining valid v1 compliance.
How does UUID v7 handle high-concurrency generation within the exact same millisecond?
RFC 9562 provides two mechanisms for sub-millisecond concurrency: allocating part of the 12-bit "rand_a" field as an incrementing monotonic counter, or relying on 74 bits of cryptographically secure random entropy. With 74 bits of randomness within each millisecond slice, a system can generate thousands of IDs per millisecond per node with virtually zero risk of collision.