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.