UUID v4 vs UUID v7: Choosing the Right UUID for Your Application
Compare UUID v4 and UUID v7 — understand the differences between random and time-ordered UUIDs, database performance implications, and when to use each version.
UUID v4 vs UUID v7: The Core Difference
UUID v4 (RFC 4122) generates identifiers using 122 random bits, producing IDs that are uniformly distributed across the entire keyspace. UUID v7 (RFC 9562) embeds a Unix millisecond timestamp in the first 48 bits, with the remaining 74 bits being random. This seemingly small change has profound implications for database performance: UUID v4 causes random insertions into B-tree indexes (page splits, fragmentation), while UUID v7 appends new IDs sequentially, matching auto-increment performance. Our UUID Generator (v4) and UUID v7 Generator let you create and compare both formats.
Database Performance: UUID v4 vs UUID v7
UUID v4's random distribution causes each new row to be inserted at a random index position, forcing the B-tree to split pages and reorganize frequently. This increases write latency, bloats index size, and degrades cache locality. UUID v7's time-prefixed design appends new rows near the end of the index, reducing page splits by 80-90% and improving insert throughput by 2-5x on PostgreSQL and MySQL benchmarks. For tables with millions of rows, the performance gap widens significantly. UUID v7 also improves range queries — SELECT * FROM users WHERE id BETWEEN ? AND ? benefits from sequential storage.
When to Use UUID v4
UUID v4 remains the better choice when you need unpredictability — for example, generating opaque public identifiers for API resources, creating session tokens, or preventing sequential ID enumeration by users. UUID v4 is also the most widely supported UUID version across languages, libraries, and databases. If you have an existing system using UUID v4, the migration cost to v7 often outweighs the performance benefit for small-to-medium databases (under 10 million rows). For distributed tracing and event sourcing where ID order is irrelevant, v4's simplicity wins.
When to Use UUID v7
UUID v7 is ideal for primary keys in OLTP databases, time-ordered event streams, chat message IDs, financial transaction IDs, time-series data, and any use case where insert performance and B-tree index health matter. PostgreSQL users benefit most — CockroachDB has adopted UUID v7 as its default key encoding. If you're starting a new project with a relational database, UUID v7 should be your default choice for primary keys. The time component also enables chronological sortability without a separate created_at column.
UUID v7 Implementation and Support
UUID v7 support is growing rapidly. Python 3.14+ includes uuid.uuid7() in the standard library. Go's google/uuid package supports v7 via uuid.NewV7(). Node.js needs a polyfill (uuidv7 npm package). PostgreSQL doesn't natively generate UUID v7 but can use extensions or application-layer generation. MySQL 8.0+ accepts UUID v7 values in BINARY(16) columns. Most UUID libraries still default to v4, so you may need to explicitly request v7. Our UUID v7 Generator provides client-side v7 generation that works in any browser.
Use our free online tool to get started instantly.