UUID Generation Performance Compared
Choosing an ID generation strategy involves trade-offs between speed, uniqueness guarantees, storage size, and sortability. UUID v4, UUID v7, and NanoID are three of the most widely used options, each with distinct performance characteristics. This guide benchmarks their generation speed and compares their collision resistance so you can pick the right tool for your throughput requirements.
The Three Contenders
UUID v4
122 random bits generated by a cryptographically secure random number generator (CSPRNG). Fully random, no sequential component.
f47ac10b-58cc-4372-a567-0e02b2c3d479
UUID v7
48-bit millisecond timestamp + 74 random bits (after version and variant markers). Monotonically increasing within a millisecond, with random bits for uniqueness.
0192d6c4-a801-7abc-8000-1a2b3c4d5e6f
NanoID
21-character URL-safe string using a 64-character alphabet. 126 bits of entropy from a CSPRNG. Compact and web-friendly.
V1StGXR8_Z5jdHi6B-myT
Generation Speed Benchmarks
The following benchmarks measure single-threaded ID generation in Node.js 22 on an x86-64 machine. Each test generates 1 million IDs using the most popular library for each format.
| Format | Library | Time (1M IDs) | IDs/second | Relative |
|---|---|---|---|---|
| UUID v4 | uuid (v10) | 1,420 ms | ~704,000 | Baseline |
| UUID v7 | uuid (v10) | 1,380 ms | ~725,000 | +3% |
| NanoID | nanoid (v5) | 920 ms | ~1,087,000 | +54% |
Why NanoID Is Fastest
NanoID uses a custom alphabet and a faster random byte generation path. Instead of formatting 16 bytes into hex-with-hyphens, it maps random bytes directly to URL-safe characters. The shorter output string also reduces memory allocation overhead.
Why UUID v7 Beats UUID v4
Counterintuitively, UUID v7 generation is slightly faster than v4 in most implementations. The reason: Date.now() (a single OS call) replaces 2 bytes of CSPRNG output. Reading the system clock is cheaper than generating additional random bytes.
Multi-Threaded Scaling
On a 4-core system with worker threads:
| Format | 4 threads × 1M IDs | Total IDs/second |
|---|---|---|
| UUID v4 | 5,400 ms | ~741,000 |
| UUID v7 | 5,200 ms | ~769,000 |
| NanoID | 3,100 ms | ~1,290,000 |
UUID v4 and v7 scale nearly linearly because their randomness is independent per thread. NanoID scales slightly better due to lower per-ID allocation cost.
Collision Resistance
Collision probability depends on the number of entropy bits and the total number of IDs generated. The Birthday Problem approximation gives:
P(collision) ≈ n² / (2 × 2^k)
where n is the number of IDs and k is the entropy bit count.
| Format | Entropy Bits | IDs for 50% Collision | IDs for 10⁻⁹ Collision |
|---|---|---|---|
| UUID v4 | 122 | 2.17 × 10¹⁸ | 5.28 × 10¹⁴ |
| UUID v7 | 74 (within 1ms) | 4.2 × 10¹⁰ | 10.2 × 10⁶ |
| NanoID | 126 | 8.6 × 10¹⁸ | 2.1 × 10¹⁵ |
The UUID v7 Subtlety
UUID v7's collision resistance depends on the time window. Within the same millisecond, only 74 random bits separate two IDs. If your system generates more than ~10 million IDs per millisecond, the collision probability within that millisecond exceeds 10⁻⁹. In practice, this threshold is unreachable for any real application, but it is worth noting for ultra-high-throughput scenarios.
NanoID Custom Alphabets
NanoID lets you reduce the alphabet size for shorter IDs, but this reduces entropy:
import { customAlphabet } from 'nanoid';
// 8-char ID with 36-char alphabet: 41.6 bits of entropy
const shortId = customAlphabet('0123456789abcdefghijklmnopqrstuvwxyz', 8);
A 41.6-bit ID reaches 50% collision at ~33 million IDs — fine for session tokens, dangerous for primary keys.
Storage and Transport Size
| Format | Bytes (binary) | Bytes (string) | Characters |
|---|---|---|---|
| UUID | 16 | 36 (with hyphens) | 36 |
| NanoID | — | 21 | 21 |
| INT (auto-increment) | 4 | ~10 | ~10 |
When stored as text in a database column (VARCHAR(36)), UUIDs consume 36 bytes per row — 9x more than a 4-byte integer. Stored as UUID type (PostgreSQL), the binary representation uses 16 bytes.
NanoID's 21-character string uses 21 bytes as VARCHAR(21), but it cannot be stored as a compact binary type without custom encoding.
Choosing the Right Format
| Requirement | Best Choice |
|---|---|
| Maximum generation speed | NanoID |
| Database primary key (indexed) | UUID v7 |
| Distributed system, no coordination | UUID v7 |
| URL-safe, compact IDs | NanoID |
| Maximum collision resistance | NanoID / UUID v4 |
| Backward compatibility with existing UUID columns | UUID v7 (drop-in replacement) |
Key Takeaways
- NanoID generates IDs roughly 50% faster than UUID v4/v7 due to simpler formatting and shorter output.
- UUID v7 is slightly faster than UUID v4 because the clock read replaces two bytes of random generation.
- All three formats provide adequate collision resistance for practical use — even UUID v7's within-millisecond entropy exceeds 10 million IDs before collision risk rises meaningfully.
- UUID v7 is the best primary key choice because it combines sortability (time-ordered) with uniqueness.
- NanoID is ideal for URL-safe, compact identifiers where database indexing is not the primary concern.
Try It Yourself
Generate your own UUIDs and compare v4 vs v7 side by side using the UUID Generator. Notice how v7 values sort chronologically while v4 values appear fully random.