GUID v4 vs v7: Why You Should Care About the Shift

Most developers still reach for Guid.NewGuid(), uuid.uuid4(), or crypto.randomUUID() without thinking twice. It works, the collision risk is tiny, and v4 has been the default for years.

But databases have changed, distributed systems have matured, and the standards have moved too. In 2024, RFC 9562 introduced GUID / UUID v7 as the time-ordered option, and major runtimes have started adding support.

That does not make v4 obsolete. It just means v7 solves problems v4 was never meant to solve.

What Changed Between v4 and v7?

Both versions are 128-bit identifiers in the familiar 8-4-4-4-12 format. They look almost identical on the surface:

v4 example: 5c98eda8-b852-4eec-9960-ac2e29d734f4
v7 example: 018f3f5e-1c2d-7a9b-8f10-3c4d5e6f7a8b

The difference is in the structure.

• v4 is almost entirely random. It offers maximum unpredictability and no embedded metadata.
• v7 starts with a Unix timestamp in milliseconds, then adds randomness. Newer IDs sort naturally by creation time.

For collision resistance, both are safe in real-world systems. The real difference is ordering and database behavior.

Why v7 Matters for Databases

This is where v7 becomes interesting.

Random v4 values land all over a B-tree index. Over time, that can cause page splits, fragmentation, and extra write overhead. The more you insert, the more noticeable it gets.

v7 changes that pattern. Because new values are time-ordered, inserts tend to cluster near the end of the index. That means fewer splits, better write performance, and less index bloat.

In practice, this can make a noticeable difference on PostgreSQL, MySQL, SQL Server, and similar systems, especially at scale. You also get approximate chronological ordering for free, which can simplify pagination, logs, and “latest first” queries.

Language Support Is Already Here

The move to v7 is not theoretical. Support is already landing across common runtimes.

• .NET: Guid.CreateVersion7()
• Python: uuid.uuid7()
• Node.js: available through the uuid package
• Go: uuid.NewV7()
• Rust: Uuid::now_v7()

The migration is usually just a one-line swap. Same storage type, same format, no central coordinator needed.

When v4 Is Still the Better Choice

v7 is not the universal answer.

If the identifier is public-facing and should not reveal creation time, v4 is still safer. That applies to URLs, API keys, session tokens, and other externally visible identifiers.

v4 also makes sense if your system already uses it everywhere and you do not need ordering benefits. If nothing is broken, there is no need to change it.

And if your environment has unreliable clocks, v7 can be less attractive because its time-based ordering depends on a reasonably accurate timestamp.

A Simple Rule of Thumb



ScenarioBest choiceDatabase primary keys for a new projectv7Public API keys or tokensv4Event streams, audit logs, correlation IDsv7Existing stable v4 systemStay with v4

The key is to make the choice deliberately instead of defaulting to habit.

Final Thoughts

GUID / UUID v7 is becoming the new default for good reason. It improves index locality, helps at scale, and fits modern distributed systems well.

That said, v4 is not dead. It is still the right option when privacy matters most or when an existing system is already working well.

The best approach is simple: choose the version that matches the job.

If you enjoyed this post, follow me for more content like this!

Thanks for reading. — Bruno