UUID v4 vs UUID v7: Which One Should You Use?

UUID database design identifiers

Choosing a UUID version used to be easy because most people defaulted to v4 and moved on. That is changing now that UUID v7 offers a practical advantage many systems actually care about: time ordering. The question is no longer just "Do I need a globally unique ID?" Both v4 and v7 can handle that in realistic workloads. The real question is whether your identifiers also need better insertion behavior in databases, more natural chronological ordering, or a cleaner operational fit for write-heavy systems. Toolnar's UUID Generator is useful for comparing these versions because it shows the structural difference between random v4 identifiers and time-ordered v7 identifiers while letting you generate either format locally in the browser.

Start with what both versions already solve

Both UUID v4 and UUID v7 are 128-bit identifiers. Both are designed so systems can generate IDs independently without relying on a central sequence generator. That makes them useful for:

  • distributed systems
  • client-side ID creation
  • replicated databases
  • public-facing identifiers
  • event-driven systems
  • merge-heavy data workflows

This shared foundation is important because it prevents a false debate. The choice is not between one version that is unique and another that is not. For practical software engineering purposes, both are suitable unique identifiers.

The decision is about the behavior around uniqueness:

  • randomness
  • sortability
  • storage patterns
  • write locality
  • operational convenience

That is where v4 and v7 begin to diverge meaningfully.

UUID v4 optimizes for pure randomness

UUID v4 is the traditional random UUID. Toolnar describes it as a 128-bit value with 122 bits of cryptographically random data, with the remaining bits used to encode the version and RFC variant.

The main appeal of v4 is simple:

  • no timestamp leakage
  • no sequencing clue
  • extremely low collision probability
  • straightforward mental model

Use v4 when the only thing you really need is a unique identifier and you do not care whether IDs sort in creation order.

That makes v4 a good fit for:

  • public URLs
  • token references
  • client-generated IDs
  • APIs where order is irrelevant
  • systems where IDs are not used as insertion-sensitive primary keys

Toolnar also notes that the collision probability is astronomically low, roughly 1 in 5.3 × 10^36, which is effectively impossible for realistic application workloads. So if randomness is the goal, v4 remains an excellent default.

UUID v7 adds chronological order without giving up uniqueness

UUID v7 changes the trade-off by encoding a 48-bit Unix timestamp in milliseconds into the most significant bits and filling the rest with random data. Toolnar summarizes this well: v7 UUIDs are time-ordered, meaning they sort lexicographically in the order they were created.

That one property changes a lot.

When IDs sort roughly by creation time, they become more operationally convenient for:

  • database primary keys
  • insertion-order scans
  • recent-first diagnostics
  • event logs
  • systems where row locality matters

This is why v7 exists. It keeps the decentralized uniqueness benefits of UUIDs while behaving more predictably under write-heavy storage patterns.

Within the same millisecond, ordering is still random, so v7 is not a perfect sequence number. But it is ordered enough to create meaningful benefits over fully random v4 in many storage contexts.

Database behavior is where the difference matters most

The most practical reason to choose v7 over v4 is database index behavior. Toolnar's FAQ makes this explicit: random v4 UUIDs can cause index fragmentation over time, especially in B-tree indexes used by systems like PostgreSQL, MySQL, and SQLite. New rows land in more scattered positions because the key space is random.

That can lead to:

  • less efficient insertion patterns
  • more page splits
  • weaker locality in clustered storage
  • more index churn at scale

UUID v7 reduces this problem because the timestamp prefix causes newly generated IDs to cluster more naturally near other recently generated IDs. That improves insertion locality without requiring a separate sequential ID generator.

If your UUIDs will live as database primary keys in a write-heavy application, that is usually the strongest argument for v7.

If the UUID is mostly a public identifier and not the main indexing surface, that argument weakens and v4 may still be the simpler choice.

Public exposure is safe in both cases, but the meaning differs

Toolnar notes that UUIDs are safe to expose publicly in URLs because they do not leak simple sequential information the way incremental integers do. That is true for both v4 and v7.

Still, there is a nuance worth understanding. v4 is purely random, so it reveals nothing about creation timing. v7, by design, contains time-order information in the most significant bits. That does not expose a human-readable timestamp directly in ordinary use, but it does mean the identifiers carry ordering semantics.

For many applications, that is perfectly acceptable and even useful. For others, pure randomness is preferable because you want less hint of record chronology in public-facing identifiers.

This is not usually a security blocker. It is an information-shape decision.

Format and storage choices matter after version choice

Version choice is only one part of UUID usage. Toolnar also supports several output formats:

  • standard lowercase
  • uppercase
  • no hyphens
  • braces

These are not just cosmetic. The no-hyphens format is often useful when storing UUIDs as BINARY(16) or compact hex strings. Toolnar's FAQ notes that BINARY(16) with stripped hyphens is often the most storage-efficient choice in MySQL or MariaDB-style environments.

Braces are useful in Microsoft GUID-style environments.

So after choosing v4 or v7, you still need to choose the representation that fits your platform, database type, or integration boundary best.

This is another reason the v4 versus v7 decision should be made in system context rather than as an abstract standards debate.

A simple decision rule works surprisingly well

Most teams do not need a long philosophy here. A short rule usually works.

Choose v4 when:

  • you want pure randomness
  • chronological sortability does not matter
  • the UUID is mainly public-facing or application-level
  • database insertion locality is not an important concern
  • you want the simplest traditional default

Choose v7 when:

  • the UUID will be a database primary key
  • insertion order matters operationally
  • you want better B-tree behavior over time
  • approximate creation-time sortability is useful
  • you do not want a separate sortable key just to recover write order

That is the practical difference most teams actually care about.

Conclusion

UUID v4 and UUID v7 both solve uniqueness well. The real choice is between randomness-first behavior and time-ordered behavior. If your IDs mostly need to exist, v4 is still a strong and simple default. If your IDs also need to behave well under database insertion and chronological sorting, v7 is usually the better option.

If you want to compare both formats directly and generate whichever one fits your system, UUID Generator is a practical starting point. The best version is not the newer one by default. It is the one whose behavior matches how your application stores, orders, and exposes identifiers.

← Back to Blog