UUID Versions: Technical Comparison and Selection Criteria

UUID Fundamentals

A UUID (Universally Unique Identifier) comprises 128 bits, typically represented as 32 hexadecimal characters with hyphen separators in 8-4-4-4-12 grouping:

550e8400-e29b-41d4-a716-446655440000

The value proposition: globally unique identifiers without central coordination. Multiple systems generating UUIDs independently produce non-colliding values with overwhelming probability. This enables distributed systems to create identifiers without synchronization overhead.

GUID Equivalence

Microsoft documentation uses GUID (Globally Unique Identifier) terminology. The format and generation algorithms are identical to UUID. When encountering GUID in .NET or Windows contexts, treat it as UUID equivalent.

Version Characteristics

Five UUID versions exist, though three see practical use:

• Version 1: Timestamp + MAC address based
• Version 2: DCE Security (rarely used)
• Version 3: MD5 hash of namespace + name (deprecated in favor of v5)
• Version 4: Random generation (most common)
• Version 5: SHA-1 hash of namespace + name

Version 4: Random Generation

Technical Mechanism

UUID v4 generates 122 random bits (6 bits reserved for version and variant markers). This randomness provides no embedded information—the identifier is purely opaque.

// Modern browser and Node.js generation
const uuid = crypto.randomUUID();
// Result: "7c9e6679-7425-40de-944b-e07fc1f90ae7"

Collision Probability

With 122 random bits, the UUID space contains approximately 5.3 × 10³⁶ possible values. Generating 1 trillion UUIDs creates collision probability around 1 in 100 billion. For practical applications, collision risk approaches zero.

Use Cases

V4 serves as the default choice for most applications. The random distribution works well across distributed systems without coordination. Database systems, distributed caches, and message queues all handle v4 UUIDs effectively.

Version 1: Timestamp-Based Generation

Structure

UUID v1 combines timestamp (60 bits), clock sequence (14 bits), and MAC address (48 bits). This embedding provides temporal ordering and node identification—sometimes useful, often problematic.

Privacy Concerns

MAC address inclusion creates privacy exposure. The identifier reveals the generating machine, potentially enabling tracking across systems. For user-facing identifiers or public APIs, this represents a significant liability.

Temporal Ordering

The timestamp component provides natural chronological ordering. Database indexes on v1 UUIDs maintain insertion order, potentially improving performance for time-series data. However, clock synchronization issues can create ordering anomalies in distributed systems.

Version 5: Deterministic Generation

Hash-Based Approach

V5 generates UUIDs by hashing a namespace identifier plus a name. Given identical inputs, v5 produces identical outputs deterministically. This reproducibility enables certain patterns impossible with random generation.

// Same inputs always produce same UUID
const namespace = '6ba7b810-9dad-11d1-80b4-00c04fd430c8';
const name = 'example.com';
// Result: always "cfbff0d1-9375-5685-968c-48ce8b15ae17"

Use Cases

Content-addressable storage systems benefit from v5. Identical content produces identical UUIDs, enabling deduplication without central coordination. URL shorteners, distributed caching, and content delivery networks leverage this property.

Namespace Selection

The UUID specification defines standard namespaces for DNS, URLs, OIDs, and X.500 DNs. Custom namespaces are permissible but should themselves be UUIDs to maintain proper distribution.

Performance Considerations

Storage Overhead

UUIDs require 16 bytes versus 4 bytes for 32-bit integers or 8 bytes for 64-bit integers. For tables with millions of rows, this overhead becomes measurable. However, the distributed generation capabilities often justify the cost.

Index Performance

Random v4 UUIDs can fragment database indexes. Each insertion occurs at a random location, preventing efficient sequential writes. Sequential UUID variants (like ULID or UUID v6 proposals) address this issue while maintaining uniqueness guarantees.

Generation Cost

Modern cryptographic random number generators produce v4 UUIDs efficiently. Generation typically costs microseconds. V1 requires timestamp and MAC address retrieval, adding minimal overhead. V5 hashing costs more but remains negligible for most applications.

Implementation Best Practices

Default to V4

Unless specific requirements dictate otherwise, v4 random identifiers serve most use cases well. The simplicity, privacy preservation, and wide support make v4 the sensible default.

Avoid V1 for Public Identifiers

The MAC address embedding in v1 creates privacy concerns. For any user-facing or public API scenario, choose v4 instead. Internal systems with controlled access may use v1 when temporal ordering provides value.

Use V5 for Deterministic Scenarios

When you need reproducible identifiers from known inputs, v5 provides the solution. Content addressing, caching strategies, and distributed deduplication all benefit from this determinism.

Addressing Common Questions

Practical Guidance

UUID version selection requires understanding your specific requirements. V4 handles most cases effectively with minimal complexity. V1 provides temporal ordering at the cost of privacy concerns. V5 enables deterministic generation when reproducibility matters.

For new implementations, start with v4. Only deviate when specific technical requirements justify the additional complexity. The robustness and simplicity of random generation serve most applications well.