UUID Guide for Developers: Which Version to Use and Why v4 Became the Default

Integer auto-increment IDs are simple and familiar — but they create significant problems in distributed systems and public APIs. UUIDs solve these problems with important tradeoffs worth understanding before making architectural decisions.

UUID Versions Compared

• v1: timestamp + MAC address — time-ordered but leaks device information and creation time
• v3: deterministic, MD5-hashed from namespace + name — same inputs always give same UUID
• v4: 122 bits of random entropy — the most widely used version
• v5: like v3 but SHA-1 — preferred over v3 for new implementations
• v7: millisecond Unix timestamp + random bits — time-ordered without MAC exposure, better DB index performance than v4

Why v4 Won

UUID v4 requires no coordination — no timestamp server, no MAC address, no central authority. Any node generates an ID independently with statistical certainty it will not collide with any UUID anywhere in the world. Probability of a duplicate among one trillion v4 UUIDs: 1 in 5.3 × 10²⁴.

The Database Performance Tradeoff

B-tree indexes perform best with sequential insertions. Random UUIDs insert anywhere in the index, causing page splits that degrade write performance at scale. For most applications at typical data volumes, this is not a practical concern. For high-write systems, UUID v7 or ULID (time-ordered random identifier) provides distributed generation benefits with sequential insertion characteristics.

Use UUID When

You are building a distributed system; you are exposing IDs in public URLs (sequential integers reveal record count and enable enumeration); you are merging records from multiple databases; or you are generating IDs client-side before a server round trip.

Generating UUIDs

UltraToolkit's UUID Generator produces v4 UUIDs one at a time or in bulk up to 100. All generation uses the Web Crypto API in your browser — never transmitted or logged.

UUID in Distributed System Design

Distributed systems — where multiple servers generate data independently and must later merge or synchronise — require identifier generation that works without coordination. Auto-increment integers require a central database sequence generator; if two servers both try to generate the next ID simultaneously, they must coordinate to avoid collisions. UUID v4 generation requires no coordination — each server generates identifiers independently with negligible collision probability, making UUID the natural choice for multi-region deployments, microservice architectures, and event-driven systems where events may be generated across many independent services.

Event sourcing systems use UUIDs for three distinct identifier types: aggregate IDs (the entity being described), event IDs (each individual event), and correlation IDs (tracking a user action across all the events it generates). The correlation ID pattern is particularly useful for debugging — when a user action triggers 15 events across 6 services, searching logs by correlation ID reveals the complete causal chain from action to effect across all services simultaneously.

UUID Collision Probability in Practice

UUID v4 collision probability is negligible for any real application. To have even a 1% chance of collision, you would need to generate approximately 360 quadrillion UUIDs (3.6 × 10^17). At a rate of one billion UUIDs generated per second, reaching this quantity would take over 11 years of continuous generation. Real-world applications that generate millions of UUIDs per day will not experience collisions within any reasonable planning horizon.

The practical risk is not mathematical collision but implementation error: using a weak random number generator, incorrectly sharing random seed state between threads, or generating UUIDs from predictable sources (timestamps alone, sequential numbers with UUID formatting). Using a cryptographically secure random number generator — the Web Crypto API in browsers, /dev/urandom on Linux, CryptGenRandom on Windows — is the only correct implementation. Libraries that wrap these OS-level CSPRNG sources are universally preferred over custom UUID implementations.