For years, UUID v4 has been the go-to standard for generating unique identifiers. It's simple, widely supported, and virtually collision-free. But it has a major flaw when used as a primary key in databases: it's completely random.

The Problem with UUID v4

Relational databases like PostgreSQL and MySQL use B-tree indexes for primary keys. When you insert a new record with a random UUID v4, the database has to insert it into a random position in the index. This leads to:

  1. Index Fragmentation: Pages are split frequently, leaving empty space.
  2. Random I/O: The database has to load different pages from disk to insert new records, killing write performance.
  3. Cache Thrashing: The "hot" part of the index is scattered across memory, reducing cache efficiency.

Enter UUID v7

UUID v7 solves this by being time-sortable (or k-sortable). It embeds a timestamp in the first 48 bits, followed by random bits.

| 48 bits (Timestamp) | 12 bits (Ver + Seq) | 62 bits (Random) |

This structure means that new UUIDs are always "greater" than older ones (roughly). When you insert them into a database:

  • Sequential Inserts: New records go to the "end" of the index.
  • Reduced Fragmentation: Pages are filled sequentially.
  • Better Performance: It behaves much like an auto-incrementing integer but retains the distributed nature of UUIDs.

Benchmarks

In tests with PostgreSQL, switching from UUID v4 to v7 can improve insert performance by 25-50% on large datasets, simply because of reduced I/O overhead.

How to Generate UUID v7

You don't need complex libraries to start using UUID v7. Our ID Forge tool supports generating UUID v7 instantly.

  1. Open ID Forge.
  2. Select UUID v7 mode.
  3. Generate as many IDs as you need.

Conclusion

If you are starting a new project, there is almost no reason to use UUID v4 anymore. UUID v7 offers the same collision resistance with significantly better database performance.

Start generating UUID v7 today and future-proof your application.