UUID v4 Generator

UUID versions — v1 through v7 explained

UUID has seven versions defined across two RFCs, each using a different strategy for generating unique identifiers.

Version 1 (time-based): embeds the current timestamp and the MAC address of the generating machine. It guarantees uniqueness across machines and time, but exposes the generating machine's MAC address — a privacy concern. The timestamp component also makes sequential UUIDs, which can be advantageous for database index performance.

Version 3 and 5 (name-based): generate UUIDs deterministically from a namespace and a name (any string). Version 3 uses MD5 hashing; Version 5 uses SHA-1. The same namespace + name always produces the same UUID — useful for content-addressable identifiers.

Version 4 (random): 122 bits of cryptographic randomness with 6 bits reserved for version and variant markers. This is the most widely used UUID format — generated by this tool. The collision probability is astronomically low (roughly 1 in 5.3 × 10³⁶ for any two UUIDs).

Version 6 and Version 7 (newer standards, RFC 9562, 2024): Version 7 is time-ordered with millisecond precision and 74 bits of randomness. Unlike v1, it uses a simple Unix timestamp (not Gregorian time) and is monotonically increasing within the same millisecond. UUID v7 is becoming the preferred choice for database primary keys because sequential insertion avoids B-tree fragmentation.

UUID vs ULID vs NanoID — choosing a unique identifier format

UUID v4 is not the only option for distributed unique identifiers. Several alternatives have emerged to address specific limitations.

ULID (Universally Unique Lexicographically Sortable Identifier) encodes a 48-bit Unix timestamp followed by 80 bits of randomness, formatted as a 26-character base32 string (e.g., 01ARZ3NDEKTSV4RRFFQ69G5FAV). ULIDs are sortable — lexicographic order matches chronological creation order — which makes them useful for database pagination and time-series data. They are also URL-safe and case-insensitive.

NanoID is a smaller, faster, URL-friendly random ID generator. By default it generates 21-character IDs using a 64-character alphabet (A-Za-z0-9_-), which provides approximately 126 bits of randomness — comparable to UUID v4. The smaller size (21 vs 36 characters) reduces storage and URL length. It is popular in web applications where compactness matters.

For most applications, the choice comes down to: use UUID v4 (or v7) when interoperating with systems that expect RFC 4122 UUID format. Use ULID when time-sortability matters (event streams, audit logs, database primary keys with chronological access patterns). Use NanoID when compactness and URL-safety are priorities (short IDs in URLs, session tokens, reference codes).

UUID as a database primary key — the trade-offs

Using UUID v4 as a primary key in a relational database (PostgreSQL, MySQL) offers several benefits but also creates a significant performance problem at scale.

Benefits: UUIDs can be generated by the application layer without a database round-trip, enabling batch inserts without coordination. Multiple services can independently create records without risk of ID collision. UUIDs are opaque — they don't expose insertion order or row count to clients, unlike sequential integers.

The performance problem: UUID v4 values are random, so new records insert at random positions in the primary key B-tree index. This causes frequent page splits, poor cache utilization (index pages scattered across storage), and increased I/O. At hundreds of millions of rows, the performance penalty compared to sequential integers (BIGINT AUTO_INCREMENT) becomes significant.

Solutions: UUID v7 addresses this by making UUIDs time-sorted — new records always insert near the end of the index. PostgreSQL's native UUID type stores UUIDs as 16-byte binary (more efficient than the 36-character string). For PostgreSQL, consider storing UUIDs as bytes rather than text. Alternatively, use a BIGINT primary key internally and expose UUID (derived from a separate UUID column) in the public API.