What Is a UUID and When Should You Use One?
UUIDs (Universally Unique Identifiers) are 128-bit identifiers designed to be unique without a central coordinator. Learn the difference between UUID versions, when to use each, and the trade-offs compared to sequential IDs.
What Is a UUID?
A UUID (Universally Unique Identifier), also known as a GUID (Globally Unique Identifier), is a 128-bit value typically written as 32 hexadecimal digits in 5 groups separated by hyphens:
550e8400-e29b-41d4-a716-446655440000
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Here, M indicates the version and N indicates the variant. UUIDs are defined in RFC 4122.
UUID Versions Explained
UUID v1 (Time-based)
Generated from the current timestamp + the MAC address of the network interface. Guarantees uniqueness in time and space but leaks the generator's MAC address (a privacy concern). V1 UUIDs from the same machine at the same time are sequential, which is useful for time-ordered records.
UUID v3 and v5 (Name-based)
Deterministic — the same namespace + name always produces the same UUID. V3 uses MD5, V5 uses SHA-1.
// The same input always produces the same output
uuidv5("hello@example.com", uuidv5.DNS); // always the same UUID
Useful when you need a stable, reproducible identifier from known inputs (e.g., deduplication).
UUID v4 (Random)
Generated from 122 bits of cryptographically random data (the remaining 6 bits encode the version and variant). This is the most widely used version — simple, fast, and produces statistically unique identifiers without any coordination.
The probability of a collision with v4 UUIDs is astronomically low. Generating 1 billion UUIDs per second for 100 years, the probability of a single collision is approximately 50% — and that's after generating about 2.7 × 10¹⁸ UUIDs. In practice, you will never encounter a collision.
UUID v7 (Time-ordered Random)
A newer version (RFC 9562, 2024) that combines a Unix timestamp prefix with random bits. This gives v7 the uniqueness of v4 with the sortability of v1, and it does so without leaking the MAC address.
UUID v7: 018e7adf-5b12-7349-8a24-6c8b7f4b2a13
^^^^^^^^^^^^ ← millisecond timestamp prefix
UUID v7 is now the recommended choice for new applications that need database-friendly sortable IDs.
UUIDs vs Auto-Increment IDs
| Auto-increment | UUID v4 | UUID v7 | |
|---|---|---|---|
| Uniqueness guarantee | Per-table | Global | Global |
| Sortable | Yes | No | Yes |
| Guessable | Yes | No | Partially |
| Database index performance | Excellent | Poor (random) | Good (sequential) |
| Distributed generation | Requires coordination | No coordination | No coordination |
Auto-increment IDs are efficient but require a central database to issue them — problematic in distributed or multi-master setups. UUIDs can be generated anywhere without coordination.
Why Random UUIDs Are Bad for Database Indexes
Relational databases (PostgreSQL, MySQL) typically store tables in a B-tree structure ordered by primary key. Inserting random UUID v4 as primary keys causes page splits: new rows are inserted in random positions, forcing the B-tree to rebalance frequently. This degrades insert performance significantly at scale.
UUID v7, ULID, and CUID2 all address this by using a time-ordered prefix, making sequential inserts the common case.
Generating UUIDs in JavaScript
Browser / Node.js 18+
crypto.randomUUID(); // built-in, no library needed
// "110e8400-e29b-41d4-a716-446655440000"
UUID v7 (library)
import { uuidv7 } from "uuidv7";
uuidv7(); // "018e7adf-5b12-7349-8a24-6c8b7f4b2a13"
Storing UUIDs in Databases
Store UUIDs as the native UUID type in PostgreSQL (16 bytes) rather than as VARCHAR(36) (36 bytes). The native type is more efficient for indexing and comparisons.
In MySQL, use BINARY(16) and store UUIDs as raw bytes (without hyphens) for maximum efficiency.