GUID V4 vs V7 - Comparison and Migration Guide

Version status and history

GUID / UUID v4 was defined around 1997, standardized in RFC 4122 in July 2005 and carried forward into RFC 9562 in May 2024. It remains the most popular and widely deployed version.

GUID / UUID v7 was officially standardized in RFC 9562 in May 2024. It is a modern, actively recommended version designed to address v4's limitations around sortability and database performance.

Side-by-side comparison

The table below uses the same attributes shown in the full GUID / UUID version comparison, filtered to v4 and v7.

Key differences explained

Randomness vs. time-ordering

V4 fills 122 of its 128 bits with cryptographically random data. The result is an identifier with no inherent order, no embedded metadata and maximum privacy.

V7 dedicates the first 48 bits to a Unix Epoch timestamp in milliseconds and fills the remaining bits (after version/variant) with randomness (or a counter). This means v7 GUIDs / UUIDs generated later are lexicographically greater, which databases and indexes can exploit.

Database and index performance

Random v4 keys scatter inserts across B-tree pages, causing page splits and lower cache locality in many databases. V7's sequential-ish nature reduces these problems significantly and often approaches the insert performance of auto-increment integers.

For more detail, see our GUID / UUID Database Performance and Indexing guide.

Privacy and metadata exposure

V4 reveals nothing about when, where or by whom it was generated, making it safe for public-facing URLs and API keys where timing metadata must stay private.

V7 embeds an approximate creation timestamp (millisecond precision) in the first 48 bits. Anyone with access to the GUID can extract the creation time. If timestamp privacy is critical, v4 is the safer choice.

Collision probability

V4 has 122 random bits, giving roughly 5.3 × 10³⁶ possible unique values. To put this in perspective: even if you generated 1 billion GUIDs / UUIDs per second, non-stop, for 100 years, the probability of producing a single duplicate is still effectively zero.

V7 has 74 random bits per millisecond, giving roughly 1.9 × 10²² unique values per millisecond. Even if you generated 1 trillion GUIDs / UUIDs within the same millisecond, the probability of a collision would still be less than 1 in 18 million. Combined with the 48-bit timestamp (which provides uniqueness across different milliseconds), v7's total collision space is similarly vast.

In short: v4 has more randomness per individual ID, while v7 adds time-based separation on top of its randomness. Both versions have effectively zero collision risk in any practical scenario.

UUID v7 is replacing v4 — here's why

1. Modern databases expect ordered keys

The most impactful advantage of v7 is its time-ordered structure. When used as a primary key, v7 GUIDs / UUIDs insert near the end of B-tree indexes rather than at random positions. This dramatically reduces page splits, write amplification and index bloat in PostgreSQL, MySQL, SQL Server and most other relational databases. Many teams that switched from v4 to v7 report measurable improvements in write throughput and reduced storage overhead.

2. Built-in chronological sorting for free

V7 gives you approximate creation-time ordering without an extra created_at column. Sorting by the primary key yields a roughly chronological list, which simplifies pagination, event streaming, audit logs and "latest first" queries. With v4 you need a separate indexed timestamp column to get the same behavior.

3. RFC 9562 codifies v7 as the recommended time-ordered version

The RFC 9562 standard (May 2024) explicitly introduces v7 as the preferred time-ordered UUID, superseding older approaches like v1 and v6. Language runtimes and libraries are rapidly adding native v7 support: Python 3.13+ (uuid.uuid7()), .NET 9+ (Guid.CreateVersion7()), Go's google/uuid v1.4+, Rust's uuid crate v1.3+, and Node.js uuid v9+.

4. Same decentralized generation model

Just like v4, v7 can be generated independently on any node without coordination, central authority or shared state. Migrating from v4 to v7 requires no infrastructure changes — only swapping the generation call.

5. Minimal trade-offs

The only meaningful cost of v7 is timestamp disclosure: the first 48 bits reveal when the GUID / UUID was created. For internal IDs (database PKs, message queues, microservice correlation IDs) this is rarely a concern. For truly public-facing tokens where timing must stay secret, v4 is still the right choice.

When v4 is still the better choice

• Privacy-sensitive public identifiers: if revealing creation time is unacceptable (e.g., in URLs or API keys visible to end users).
• Existing v4 ecosystems: if your system already uses v4 everywhere and ordering brings no benefit, switching adds churn without gain.
• Maximum randomness per ID: v4's 122 random bits vs. v7's 74 random bits per millisecond. For extremely paranoid collision avoidance within a single time-tick, v4 offers a wider spread.
• Stateless environments without reliable clocks: v7 depends on a reasonably accurate system clock. If your environment has unreliable time (some embedded systems, sandboxed environments), v4 avoids clock-related issues entirely.

Advantages of GUID / UUID v4

• No coordination required: generated independently on any machine without a central authority.
• High security and privacy: contains no timestamps, MAC addresses or embedded metadata.
• Simple and widely supported: implemented in virtually all languages, databases and frameworks.
• Stateless generation: no counters, clocks or shared state needed.
• Fast and scalable: generation is CPU-cheap and parallel-friendly.

Advantages of GUID / UUID v7

• Time-ordered (practical sorting): the leading millisecond timestamp makes v7 GUIDs / UUIDs sortable by creation time.
• Great for databases: reduces random insert patterns and index fragmentation compared to v4.
• Distributed-friendly: can be generated independently on many nodes without coordination.
• Low collision risk: combines a timestamp prefix with substantial randomness.
• Modern standard: standardized in RFC 9562 (May 2024).

Warnings and considerations

Technical details comparison

Both versions are 128-bit identifiers using the standard 8-4-4-4-12 canonical format (32 hex digits + 4 hyphens = 36 characters). They differ in how those 128 bits are allocated.

V4 field structure

Field Name                   Bits  Hex    Description
─────────────────────────────────────────────────────────────────────────
random_low                   32    8      32 random bits
random_mid                   16    4      16 random bits
random_hi_and_version        16    4      12 random bits + 4-bit version (0100)
random_seq_hi_and_reserved   8     2      2-bit variant (10) + 6 random bits
random_seq_low               8     2      8 random bits
random_node                  48    12     48 random bits
                

V7 field structure

Field Name                   Bits  Hex Digits  Description
─────────────────────────────────────────────────────────────────────────
unix_ts_ms                   48    12          Unix Epoch timestamp in milliseconds (big-endian)
ver                          4     1           4-bit version field (0111 = 7 in hex)
rand_a                       12    3           12 random bits
var                          2     ~0.5        2-bit variant field (10 = RFC 4122 variant)
rand_b                       62    ~15.5       62 random bits (or counter + random)
                

Format examples

Canonical format:  8-4-4-4-12
Layout:            xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
                                 ^    ^
                                 |    └─ N = Variant: typically 8, 9, a or b (RFC variant)
                                 └────── M = Version: "4" for v4, "7" for v7

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

Try our GUID Validator to validate, decode and visualize the bit-level structure of v4 and v7 GUIDs / UUIDs.

Frequently Asked Questions

Conclusion

GUID / UUID v7 is emerging as the modern default for new applications. Its time-ordered design delivers real-world performance gains for databases, simplifies chronological queries and costs almost nothing in implementation complexity. V4 remains a solid, well-proven choice for scenarios where timestamp privacy matters or where ordering simply isn't needed.

For new projects, prefer v7 unless you have a specific reason to avoid revealing creation timestamps. For existing v4 systems, evaluate whether the performance and ordering benefits of v7 justify the switch for your workload.