UUID v4 vs. UUID v7: Which One Should You Use for Your Database?

When designing a modern database schema, one of the first decisions you'll make is choosing a Primary Key strategy. Do you use an auto-incrementing integer (1, 2, 3...) or a Universally Unique Identifier (UUID)?

Because UUIDs allow multiple distributed servers to generate unique IDs simultaneously without talking to a central database, they have become the industry standard for microservices.

But not all UUIDs are created equal. Historically, UUID v4 was the default choice. Recently, however, UUID v7 has taken the backend world by storm. Let's compare them and see which one you should be using.

The Problem with UUID v4

A standard UUID v4 looks like this: f47ac10b-58cc-4372-a567-0e02b2c3d479.

It is generated using pure randomness. There is no logic, timestamp, or machine identifier inside it—just 122 bits of cryptographic randomness.

👉 Generate one right now: You can create instant random identifiers using our UUID Generator.

While the randomness guarantees uniqueness, it creates a massive problem for relational databases like PostgreSQL and MySQL.

Databases store rows on disk using a structure called a B-Tree index. For a B-Tree to be efficient, new records should ideally be inserted in sequential order at the "end" of the tree. Because UUID v4s are entirely random, a new ID could belong at the beginning, middle, or end of the index.

This causes Index Fragmentation. As your database grows to millions of rows, the database has to constantly re-shuffle memory pages to insert new random UUIDs, leading to massive performance degradation and slow write speeds.

The Solution: UUID v7

To solve the database fragmentation problem, the IETF standardized UUID v7.

A UUID v7 looks identical to a v4 on the surface, but its internal structure is completely different. A UUID v7 replaces the first 48 bits of randomness with a Unix Timestamp in milliseconds. The remaining bits are filled with randomness to ensure uniqueness.

Why is this brilliant?

Because the first half of a UUID v7 is a timestamp, UUID v7s are naturally sortable by time.

If you generate a UUID v7 right now, and another one five seconds later, the second UUID will be alphabetically "larger" than the first one.

When you insert these into a database, the database sees sequential data. It happily appends the new rows to the end of the B-Tree index, completely eliminating the fragmentation issue that plagued UUID v4.

Which One Should You Choose?

The decision is remarkably simple in 2026:

• Are you using the UUID as a Primary Key in a relational database? Use UUID v7. The performance gains in large tables are tremendous, and you get the added benefit of being able to extract the creation date directly from the ID.
• Are you generating API keys, session tokens, or temporary file names? Stick to UUID v4. Since these don't rely on sequential database indexing, the pure randomness of v4 is perfectly suited for these tasks.

By understanding the internal structure of your identifiers, you can build faster, more scalable backend architectures from day one.