UUID v4 vs v7: Which Should You Use for Database IDs?

Every row in your database needs an ID. For years the choice was simple: auto-incrementing integers, or random UUIDs. UUID version 7, standardised in 2024 in RFC 9562, changes that trade-off, and it’s quickly becoming the default for new projects.

What is a UUID?

A UUID (universally unique identifier, also called a GUID) is a 128-bit value usually written as 36 characters:

0192f3a4-7c2e-7b1d-9f4a-3c8e2d1b6a05

The first digit of the third group shows the version, a 7 here. Because UUIDs can be created anywhere (in your app, on a phone, in different services) without asking a central database for the next number, they’re ideal for distributed systems.

UUID v4: fully random

Version 4 fills 122 of its 128 bits with random data. It reveals nothing about when or where it was made, and collisions are practically impossible: you would need to generate about a billion per second for around 85 years to reach a 50% chance of a single duplicate.

The downside appears in databases. Most databases store primary keys in a sorted B-tree index. Random IDs land at random positions in that index, so every insert touches a different page. On large tables this means more page splits, more cache misses and slower writes.

UUID v7: time-ordered

Version 7 starts with a 48-bit Unix timestamp in milliseconds, followed by random bits. IDs created later sort after IDs created earlier, so new rows are appended at the end of the index, just like auto-increment integers. You keep the benefits of UUIDs with much better database performance.

As a bonus, IDs sort roughly by creation time, which helps with pagination and debugging.

How v4 and v7 compare

• Uniqueness: both are effectively unique
• Database insert performance: v7 is much better on large tables
• Sortable by creation time: v7 yes, v4 no
• Reveals creation time: v7 yes, v4 no
• Support: v4 everywhere; v7 is newer but growing fast. PostgreSQL 18 added a built-in uuidv7() function, and libraries exist for every major language

What about auto-increment IDs?

Sequential integers are small (4 or 8 bytes versus 16) and fast. Their weaknesses are elsewhere:

• They leak information: /invoice/1043 tells a competitor how many invoices you’ve issued, and invites people to try /invoice/1044.
• They require the database to hand out each number, which is awkward for offline apps and multiple services.
• Merging data from two databases causes clashes.

A common pattern is to use integers internally and expose a UUID publicly. For new systems, a v7 UUID as the primary key is often the simplest choice.

Storage tips

• Use your database’s native UUID type (uuid in PostgreSQL, BINARY(16) in MySQL), not a 36-character string. It’s less than half the size and faster to compare.
• Generate IDs in one place consistently, either in the app or in the database.

Need test data or IDs for a migration? The free UUID Generator creates v4 or v7 UUIDs, up to 1,000 at a time, in lowercase, uppercase or with braces.