// uuid_v4 vs uuid_v7 vs ulid vs ksuid
Browser-native benchmarks measuring ID generation throughput, sortability, collision probability, and estimated database index performance. No server required.
// live_benchmark
Generates 100,000 IDs of each type and measures throughput. Results vary by CPU speed and browser engine.
// feature_matrix
Feature and performance comparison for common use cases.
| Format | Sortable | DB Index Perf. | Collision Safety | Human Readable | Speed |
|---|---|---|---|---|---|
| UUID v4 | ✗ Random | ⚠ Poor (fragmented) | ✓ Excellent | ✗ Opaque | Fast |
| UUID v7 | ✓ Time-ordered | ✓ Excellent | ✓ Excellent | ✗ Opaque | Medium |
| ULID | ✓ Time-ordered | ✓ Good | ✓ Good | ✓ Crockford Base32 | Medium |
| KSUID | ✓ Time-ordered | ✓ Good | ✓ Excellent | ✓ Base62 | Slower |
| Snowflake ID | ✓ Time-ordered | ✓ Excellent | ✓ Excellent | ✗ Opaque | Fast |
| Auto-Increment | ✓ Sequential | ✓ Best | ✗ Guessable | ✓ Numeric | Fastest |
// why_it_matters
UUID v4 generates 122 bits of random data. It's implemented in virtually every language, and its collision probability is astronomically low (~10⁻¹⁸ chance of collision at 1 trillion IDs). But there's a serious problem: it's random. Databases maintain B-tree indexes, and inserting random UUIDs causes page fragmentation — the database has to insert records into random positions in the index, causing page splits and degrading write performance as your dataset grows.
UUID v7 (finalized in RFC 9562, 2024) places a Unix timestamp in the most significant bits, followed by random data. The result is time-ordered: newer records sort after older records. This aligns with how B-tree indexes work — sequential inserts append to the end of the index rather than fragmenting it. Tests on PostgreSQL and MySQL consistently show 2–5× better write throughput with UUID v7 vs v4 at millions of records.
// UUID v4 — random, no order
550e8400-e29b-41d4-a716-446655440000
// UUID v7 — time-ordered, same safety
01966b9e-da40-7a5b-8021-c4e8a9f2d100
018f8b4e-4b23-7cde-b59f-1234567890ab
^^^^^ Monotonically increasing timestamp prefix
Use UUID v4 when: you need a proven, widely-supported format, your dataset is small, or write performance doesn't matter.
Use UUID v7 when: you need distributed ID generation, write-heavy workloads, and good database performance. This is the default choice for most new applications in 2024+.
Use ULID when: you need human-readable, copy-pasteable IDs that are also time-sortable (e.g., in URLs or logs).
Use Auto-Increment when: you have a single database node, security through obscurity isn't a concern, and you want maximum index performance.