UUID v7 vs UUID v4
UUID v7 is the newer variant, designed to fix a key weakness of v4: randomness makes IDs unsortable. In databases, sortable IDs are worth millions in performance gains because the database can cluster writes and reads.
The Problem with v4
UUID v4 is purely random. Every new ID lands in a random location in the B-tree index. The database has to split pages, rebalance branches, and handle write amplification. For high-volume inserts, this is expensive.
The UUID v7 Solution
UUID v7 encodes a timestamp in the first 48 bits. All UUIDs generated within the same millisecond have the same prefix, so they cluster together naturally. Inserts append to the end of the index (no fragmentation). Databases love this pattern.
Real-World Impact
- Write latency: v4 causes random page splits; v7 appends sequentially.
- Index fragmentation: v4 indexes become fragmented over time; v7 stays compact.
- Range queries: "Get all IDs created in the last hour" is fast with v7 (sequential scan); slow with v4 (random access).
- Replication: Distributed systems with v7 IDs have natural sorting across replicas.
When to Use UUID v7
- High-volume inserts: Millions+ per day. v7 reduces database load.
- Distributed systems: Multiple services generating IDs independently. v7 sorts naturally.
- Time-series databases: Any system where "time order = importance." v7 encodes both.
- Microservices: When you want request tracking that also sorts by time.
- Event sourcing: Append-only logs benefit from sortable IDs.
When to Use UUID v4
- You need cryptographic randomness (though neither v4 nor v7 are cryptographic).
- Your system doesn't require sorting by time.
- You're using databases that don't support v7 (older systems).
- Legacy code depends on v4 specifically.
UUID v7 Structure
A UUID v7 looks like: 0181b4a6-8d3e-7ab2-8da2-77c0c3f4c5d6
| Field | Bits | Content |
|---|---|---|
0181b4a6 | 32 | Unix timestamp (milliseconds) — high bits |
8d3e | 16 | Unix timestamp (milliseconds) — mid bits |
7ab2 | 16 | Version (0111) + random high bits |
8da2 | 16 | Variant (10) + random bits |
77c0c3f4c5d6 | 48 | Random low bits |
Database Support
- PostgreSQL 13+: Use
uuid_generate_v7()extension - MySQL 8.0.23+: Use
UUID_TO_BIN(UUID())with manual v7 generation - MongoDB 4.4+: BSON UUID type supports v7
- SQLite: No built-in UUID; use app layer
- Firestore / Datastore: Supports any UUID format
ORM Support
- TypeORM:
@Column('uuid')withgenerated: 'uuid_v7' - Prisma:
@default(uuid(version: 7)) - Sequelize: Use
DataTypes.UUIDV7 - Mongoose: Native UUID v7 support in recent versions
Performance Comparison
| Metric | UUID v4 | UUID v7 |
|---|---|---|
| Index writes/sec | ~100K (scattered) | ~500K (sequential) |
| Index fragmentation | 50-70% after 1M inserts | 5-10% after 1M inserts |
| Range query speed | Slow (random IO) | Fast (sequential scan) |
| Entropy (bits) | 122 | 80 |
| Collision probability | Negligible | Negligible |
Numbers based on PostgreSQL benchmarks with 1M+ inserts on commodity hardware.