UUID Overview
UUID (Universally Unique Identifier) is a 128-bit identifier standardized by RFC 4122. Typically represented as a 32-character hexadecimal string in 8-4-4-4-12 format (e.g., 550e8400-e29b-41d4-a716-446655440000). UUIDs enable collision-free unique identifiers without central coordination, making them essential for distributed systems as primary keys, session IDs, and filenames.
With RFC 9562 published in 2024, UUID versions 6, 7, and 8 were officially standardized. This guide focuses on v1, v4, and v7 — the versions most commonly used in practice.
UUID v1: Timestamp + MAC Address
UUID v1 combines the current time (100-nanosecond precision) with the generating node's MAC address. Being time-based, it provides natural chronological ordering and guarantees sequence for UUIDs from the same node.
However, it has two significant drawbacks. First, the MAC address is directly embedded, enabling device identification and creating privacy concerns. Second, timestamp bits are not placed in the most significant positions, so B-tree index sorting doesn't align with chronological order. For these reasons, v1 is not recommended for new projects.
UUID v4: Pure Random
UUID v4 fills 122 bits with random values. The remaining 6 bits indicate version (4) and RFC variant information. Simple to implement and containing no personal information, v4 is currently the most widely used version.
Collision probability is theoretically 1 in 2^122 (approximately 5.3 × 10^36). Even generating one billion per second, the probability of collision is negligible. Available natively via crypto.randomUUID() (JavaScript), uuid.uuid4() (Python), and UUID.randomUUID() (Java).
The downside: being fully random means no time information, so generation order is unknown. B-tree index insertion points are randomly distributed, causing frequent page splits — a major performance concern for high-volume INSERT workloads.
UUID v7: Time-Sortable Random
UUID v7, standardized in RFC 9562 (2024), combines the randomness of v4 with the chronological sorting benefits of v1. The upper 48 bits contain a Unix timestamp (milliseconds), with remaining bits filled randomly.
This structure ensures natural chronological sorting while random bits prevent collisions within the same millisecond. In B-tree indexes, new UUIDs always insert at the rightmost end, significantly improving index performance compared to v4. PostgreSQL 17 and MySQL 8.0.33+ have begun providing native v7 generation functions.
Version Comparison Summary
Generation method: v1 uses time+MAC, v4 uses pure random, v7 uses time+random. Chronological sorting: v1 is limited (bit placement issues), v4 is impossible, v7 fully supports it. Privacy: v1 exposes MAC address; v4 and v7 are safe. Index performance: v1 and v7 are good; v4 degrades under high-volume inserts.
UUID as a Database Primary Key
B-tree Index Impact
Most relational databases use B-tree indexes for primary keys. Auto-increment integer keys always insert at the rightmost end of the tree, minimizing page splits. UUID v4's random nature causes insertions at arbitrary positions, leading to frequent page splits, increased I/O, and index fragmentation.
UUID v7 inserts in a pattern similar to auto-increment keys due to its chronological nature. Benchmarks report 2-5x higher INSERT throughput for v7 compared to v4, with smaller index sizes.
Storage Optimization
Storing UUIDs as CHAR(36) uses 36 bytes, but BINARY(16) reduces this to 16 bytes. MySQL provides UUID_TO_BIN() and BIN_TO_UUID() for conversion; PostgreSQL's native UUID type automatically stores as 16 bytes. For tables with tens of millions of rows, use BINARY(16) or native UUID types.
ULID: An Alternative to UUID
ULID (Universally Unique Lexicographically Sortable Identifier) places a millisecond timestamp in the upper 48 bits and random values in the lower 80 bits. Encoded in Crockford Base32 as a 26-character string, it is case-insensitive and lexicographically sortable.
ULID was widely adopted before UUID v7 became an official standard. Since v7 is now an RFC standard, new projects should consider v7 first. Existing ULID systems don't need migration — the cost-to-benefit ratio typically doesn't justify it.
Project Selection Guide
New web services — UUID v7 is recommended. Chronological sorting ensures excellent index performance, and privacy is safe.
Microservice communication — UUID v4 is simplest. Natively supported by most languages/frameworks with minimal implementation complexity.
Log/event tracking — UUID v7 or ULID is recommended. Chronological sorting benefits log analysis and debugging.
Security tokens — UUID is an identifier, not a secret. For authentication tokens, use crypto.getRandomValues() or dedicated token libraries.
UUID Generation Tool
For quick testing or dummy data generation, use the UUID Generator. Generate 1-100 UUID v4 values with uppercase conversion and dash removal options. For text hashing needs, use the Text Hash Generator.