Why UUIDv7 Is the Future of Unique Identifiers

Most developers are familiar with UUIDs — those long, random-looking strings that uniquely identify records, sessions, or devices.
For years, UUIDv4 (random-based) has been the default, but it isn’t perfect. The new UUIDv7 standard is gaining traction because it fixes some of the issues developers run into when scaling systems.

A quick refresher: What is a UUID?

UUID stands for Universally Unique Identifier. It’s a 128-bit value usually represented as a string like:

550e8400-e29b-41d4-a716-446655440000

UUIDs are designed to be globally unique without relying on a central authority. That makes them great for:

Database primary keys
Tracking user sessions
Correlating logs and events across services
File names where collisions must be avoided

The problem with UUIDv4

UUIDv4 is random-based. While randomness ensures uniqueness, it also creates two problems:

Poor sorting
V4 UUIDs don’t follow any order, so if you use them as database keys, inserts can become fragmented. That hurts performance on large tables.
No temporal meaning
You can’t tell when a v4 UUID was generated. For debugging and event ordering, that’s a drawback.

Why UUIDv7 matters

UUIDv7 was proposed to solve these problems. It’s time-ordered, while still retaining randomness for uniqueness.

Key advantages:

Monotonic ordering
v7 encodes the current Unix timestamp in milliseconds into the UUID. This means new UUIDs will sort in creation order, which is great for database indexes.
Better performance in databases
Since v7 UUIDs are sequential by time, inserts are much faster compared to the random scatter of v4.
Debugging made easier
A v7 UUID contains a timestamp — you can roughly tell when it was created without needing extra metadata.
Still unique
The remaining bits are random, ensuring low collision probability.

UUIDv7 in action

Here are two sample v7 UUIDs:

018ec6b1-75c2-7d3a-9a8e-5d2f3c4d8b9c
018ec6b1-75c2-7d3a-9a8e-8a7f6b2c1e5d

Notice how they start with the same timestamp portion (018ec6b1...) but differ later due to random bits. This means they’re sequential but still unique.

When should you use UUIDv7?

New projects → If you’re starting a new database schema, v7 is an excellent default.
Event-driven systems → Log correlation, tracing, and event ordering benefit from the time component.
Anywhere you used v4 → v7 can be a drop-in replacement in most scenarios.

Try it yourself

Our UUID Generator now supports both v4 and v7.
👉 Generate some UUIDv7s and see how they’re ordered compared to v4.

Conclusion

UUIDv4 won’t disappear anytime soon, but UUIDv7 is a strong candidate for the new default.
It combines uniqueness with time-ordering, making it better for performance, debugging, and scalability. If you haven’t already, it’s worth experimenting with in your projects today.