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

If you are designing a database schema, building a REST API, or architecting a distributed system today, one of the first design decisions you will face is: How should we identify our records?

For over two decades, the standard default choice has been UUID Version 4—a 128-bit identifier generated almost entirely from random numbers.

However, with the official publication of RFC 9562, a new standard has taken the software development world by storm: UUID Version 7. UUID v7 combines a millisecond Unix timestamp with cryptographic randomness, creating an identifier that is naturally sorted by creation time.

This leads to the practical question every developer asks: UUID v4 vs UUID v7—which one should you actually use in your application?

In this guide, we will compare UUID v4 and UUID v7 across every critical dimension: how they work under the hood, how they impact database B-Tree indexes, privacy and security trade-offs, collision probabilities, and practical decision rules for modern software design.

1. Quick Answer: UUID v4 vs UUID v7

If you want the immediate takeaway:

Use UUID v7 for database primary keys, event logs, time-series data, and high-volume transactional tables where chronological sorting and database insert performance matter.
Use UUID v4 for public API tokens, session identifiers, password reset tokens, or any scenario where you need pure unpredictability and must not leak the exact creation timestamp.
Neither is universally “better.” UUID v7 solves database indexing bottlenecks, while UUID v4 provides maximum privacy and unpredictability.

┌────────────────────────────────────────────────────────────────────────────┐
│ • High-volume Database Primary Key? ───────► UUID v7 (Time-Ordered)        │
│ • Public API Resource / Secret Token? ─────► UUID v4 (Purely Random)       │
│ • Real-time Event Streaming / Logs? ───────► UUID v7 (Chronological)       │
│ • Existing stable system using v4? ────────► Keep UUID v4 (No rush)        │
└────────────────────────────────────────────────────────────────────────────┘

If you want to generate identifiers for either version right away, you can use our free browser-based UUID Generator to create fresh v4 and v7 IDs on demand.

2. What Is UUID v4?

UUID Version 4 is a 128-bit identifier generated using cryptographically secure pseudo-random numbers.

 9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d
                ▲
            Version 4

How UUID v4 Works

Out of the 128 total bits in a UUID:

4 bits are reserved to identify the version (0100 in binary = 4).
2 bits are reserved for the RFC variant (10 in binary).
The remaining 122 bits are filled with cryptographically strong random numbers generated by the operating system’s entropy pool (such as crypto.randomUUID() in Node.js or Guid.NewGuid() in .NET).

Key Advantages of UUID v4

Zero Information Leakage: A UUID v4 does not reveal when it was created, which server created it, or what network interface was used.
Universal Support: Every programming language, framework, and database tool on Earth has built-in support for generating and parsing UUID v4.
Decentralized Generation: Any client, server, or edge device can generate a UUID v4 locally without needing network calls or centralized locks.

Limitations of UUID v4

Completely Unordered: Because the characters are random, successive UUID v4 identifiers have no relationship to one another. When used as primary keys in B-Tree indexed databases, this randomness causes severe index fragmentation and cache misses.

3. What Is UUID v7?

UUID Version 7 is a modern 128-bit identifier standardized in RFC 9562 (May 2024). It was specifically engineered to combine the decentralized benefits of UUIDs with the index performance of auto-incrementing integers.

 018d3b7d-3b7d-7bad-9bdd-2b0d7b3dcb6d
                ▲
            Version 7

How UUID v7 Works

Instead of filling all available bits with random noise, UUID v7 arranges its 128 bits into two distinct sections:

  018d3b7d3b7d  -  7bad  -  9bdd  -  2b0d7b3dcb6d
 [  48 bits   ]   [16 b]   [16 b]   [  48 bits   ]
  Unix Epoch (ms)  Ver+Rand Var+Rand   Random Bits

48-Bit Timestamp (Bits 0–47): The most-significant bits contain a standard Unix epoch timestamp measured in milliseconds (the number of milliseconds since January 1, 1970). This counter will not overflow until the year 10889 AD.
4-Bit Version (Bits 48–51): Set to binary 0111 (7).
74 Bits of Randomness / Counter (Bits 52–127): The remaining bits contain cryptographically secure randomness, optionally paired with a sub-millisecond sequence counter to ensure strict monotonic ordering even if multiple IDs are created within the exact same millisecond.

Key Advantages of UUID v7

Naturally Time-Ordered (Monotonic): Because the timestamp is at the beginning, sorting UUID v7 values alphabetically or numerically sorts them chronologically.
High Database Write Performance: New records append smoothly to the right edge of database B-Tree index pages, preventing expensive page splits.
Human-Friendly Debugging: You can extract the exact millisecond creation timestamp directly from the identifier without needing a separate created_at column.

Limitations of UUID v7

Exposes Creation Timestamp: Anyone who sees the UUID v7 can decode the exact date and millisecond it was generated.

4. UUID v4 vs UUID v7: Side-by-Side Comparison

Here is how the two versions compare across every technical dimension:

Feature / Property	UUID v4	UUID v7
Standard Reference	RFC 4122 / RFC 9562	RFC 9562 (New Standard)
Generation Method	Pure Cryptographic Randomness	Unix Timestamp (ms) + Randomness
Timestamp Component	None (0 bits)	48-bit Unix Epoch Milliseconds
Random Bits	122 bits	74 bits (or 62 bits + sub-ms counter)
Sortability	Unsorted (Random distribution)	Naturally Time-Ordered (Monotonic)
Database B-Tree Impact	Causes page splits at scale	Clean sequential append writes
Privacy / Secrecy	Exposes no temporal data	Exposes creation date & time
Predictability	Completely unpredictable	Timestamp is predictable; payload is random
Collision Risk	$1 \text{ in } 2^{122}$ (Practically zero)	$1 \text{ in } 2^{74}$ per millisecond (Zero)
Best Used For	Public tokens, session IDs, private keys	Database primary keys, events, logs

You can check and decode the structure of both versions using our free UUID / GUID Validator.

5. Randomness vs Time Ordering: Why It Matters

To understand the core difference, imagine creating 5 new user records over the course of a few seconds:

How UUID v4 Looks Over Time (Random)

Record 1 (10:00:01 AM):  f47ac10b-58cc-4372-a567-0e02b2c3d479
Record 2 (10:00:02 AM):  1b9d6bcd-bbfd-4b2d-9b5d-ab8dfbbd4bed
Record 3 (10:00:03 AM):  a2b8c9d0-1234-4567-89ab-cdef01234567
Record 4 (10:00:04 AM):  3d4e5f60-789a-4bc1-9def-112233445566
Record 5 (10:00:05 AM):  88776655-4433-4211-9000-aabbccddeeff

Notice how the leading characters jump unpredictably between f, 1, a, 3, and 8.

How UUID v7 Looks Over Time (Time-Ordered)

Record 1 (10:00:01 AM):  018d3b7a-1200-7abc-8901-112233445566
Record 2 (10:00:02 AM):  018d3b7a-3900-7bcd-8901-223344556677
Record 3 (10:00:03 AM):  018d3b7a-6000-7cde-8901-334455667788
Record 4 (10:00:04 AM):  018d3b7a-8700-7def-8901-445566778899
Record 5 (10:00:05 AM):  018d3b7a-ae00-7efa-8901-556677889900

Notice how the leading 48 bits (018d3b7a...) increase steadily over time. If you sort these records alphabetically, they are automatically sorted in the exact chronological order they were created.

6. Database Impact: B-Trees, Page Splits, and Performance

The primary motivation behind UUID v7 was solving the notorious “UUID Primary Key Problem” in relational databases.

How Databases Store Indexes (B-Trees)

Relational databases like PostgreSQL, MySQL (InnoDB), SQLite, and SQL Server store primary key indexes using balanced tree structures called B-Trees.

A B-Tree stores data in fixed-size blocks of memory called pages (usually 8 KB or 16 KB each):

┌──────────────────────────────────────────────────────────┐
│                   Database B-Tree Index                  │
├────────────────────────────┬─────────────────────────────┤
│   UUID v7 Insert Pattern   │   UUID v4 Insert Pattern    │
│   (Sequential Append)      │   (Random Insertion)        │
│                            │                             │
│   [Page 1] [Page 2] [Page 3] [Page 1] [Page 2] [Page 3] │
│     Full     Full    ► New ◄    Split!   Split!   Split! │
└────────────────────────────┴─────────────────────────────┘

When using UUID v7: Because every new ID has a larger timestamp than the previous one, new entries are always inserted at the end of the right-most page. When a page fills up, the database simply allocates a new empty page. This is fast, efficient, and keeps index pages packed with 95%+ storage density.
When using UUID v4: Because every new ID is random, new entries must be inserted into arbitrary pages scattered across the entire database. If a target page is already full, the database must halt the write, split the 16 KB page into two half-empty 8 KB pages, and rewrite tree pointers. This process is called a B-Tree page split.

Real-World Performance Nuance

Does UUID v7 make every database 10x faster? No.

For small tables (under 1 million rows) or read-heavy applications, you will likely notice zero difference between v4 and v7 because the entire index easily fits in RAM.
For high-throughput write workloads, multi-million row tables, or mobile apps running SQLite on constrained disk I/O, UUID v7 can reduce write amplification and index bloat by 30% to 70%.

7. Privacy and Security Considerations

Choosing between v4 and v7 involves an important security and privacy trade-off.

What Does UUID v7 Expose?

Because the first 48 bits of a UUID v7 contain a Unix timestamp:

Anyone who sees a UUID v7 can determine the exact date, hour, minute, second, and millisecond the object was created.
In public APIs, this can leak business metrics. For example, if a competitor creates an account on Monday and another on Friday, they can calculate exactly how many users signed up between those two timestamps.

What Does UUID v4 Expose?

Nothing. A UUID v4 contains only random bits. An external observer cannot deduce when the account was registered, which server created it, or how many records exist.

Important Security Rule: Neither UUID v4 nor UUID v7 should ever be treated as a secret authentication password or API key. UUIDs are designed for uniqueness, not access authorization. Always use dedicated cryptographic tokens (like HMAC tokens or 256-bit random API keys) for security-sensitive credentials.

8. Collision Probability: How Safe Are They?

A common question among developers is whether reducing the random space in UUID v7 increases the risk of duplicate IDs.

Let’s examine the mathematical reality:

UUID v4 Random Space: Has 122 bits of randomness ($2^{122} \approx 5.3 \times 10^{36}$ combinations).
UUID v7 Random Space: Has 74 bits of randomness ($2^{74} \approx 1.88 \times 10^{22}$ combinations) per millisecond.

What Does This Mean in Practice?

To have a 50% chance of generating a single collision with UUID v7, a single system would need to generate billions of UUIDs within the exact same millisecond.

Furthermore, RFC 9562 allows UUID v7 generators to include a monotonic sequence counter within the random bits. If multiple IDs are generated within the same millisecond on the same thread, the counter increments, making collisions mathematically impossible within that node.

For all real-world distributed architectures, both UUID v4 and UUID v7 provide virtually zero risk of collision when generated with standard cryptographic random sources.

If you need to batch-generate thousands of test identifiers to verify uniqueness in your test suite, use our Bulk UUID Generator.

9. Real-World Scenario Guide: Which One to Choose?

Here is a practical guide for common architecture scenarios:

1. Database Primary Keys (`users`, `orders`, `transactions`)

Winner: UUID v7
Why: High insert throughput, smaller index footprint on disk, and natural sorting by creation time.

2. Public API URL Identifiers (`/api/v1/documents/{id}`)

Winner: UUID v4
Why: Protects internal creation timestamps from public exposure and prevents competitors from analyzing record creation rates.

3. Distributed Event Tracing & Log Aggregation

Winner: UUID v7
Why: Log aggregation pipelines (like Elasticsearch, Loki, or Datadog) sort incoming telemetry by time. Embedding the timestamp into the ID simplifies time-range queries.

4. Temporary Session Tokens & CSRF Identifiers

Winner: UUID v4
Why: Pure unpredictability is desirable for ephemeral browser sessions.

5. Compact Identifiers (Base64 Encoded)

Winner: Tie (Both work identically)
Both UUID v4 and UUID v7 are 128-bit numbers that can be compressed from 36 characters down to 22 URL-safe characters using our Base64 UUID Generator.

10. When Should You Choose UUID v4?

Choose UUID v4 when:

You want simple, general-purpose unique identifiers.
You do not want anyone to infer when a record was created.
You are generating public resource identifiers, invite tokens, or non-persisted IDs.
Your database tables are small, read-dominated, or use an existing auto-incrementing integer as the primary key.
You are building on legacy frameworks that do not yet have native RFC 9562 UUID v7 libraries.

11. When Should You Choose UUID v7?

Choose UUID v7 when:

You are creating primary keys for new SQL or NoSQL database tables.
You need your database to maintain fast write speeds and low index fragmentation at scale.
You want identifiers that naturally sort in chronological order without needing composite index tuples.
You are building audit trails, logging pipelines, or event-driven microservices.
Exposing the millisecond creation timestamp does not create a business privacy concern.

12. Should You Migrate Existing Systems from v4 to v7?

If your existing application already uses UUID v4 successfully, there is usually no urgent reason to perform a massive database migration.

When Migration Makes Sense:

You are experiencing severe database write latency or B-Tree index bloat on multi-million row tables.
You are already designing a new major schema revision or microservice.

When to Leave It Alone:

Your database performance is completely healthy.
Your tables contain fewer than a few million rows.
You have third-party API clients expecting completely random IDs.

In many systems, teams choose a hybrid approach: leave existing tables on UUID v4, and use UUID v7 for all new tables moving forward.

If you are working in the Microsoft .NET or Windows environment, both versions map seamlessly to the standard System.Guid type. You can generate Windows-compatible GUIDs with our GUID Generator.

13. Summary Checklist & Final Verdict

┌──────────────────────────────────────┬──────────────────────────────────────┐
│ CHOOSE UUID v4 IF:                   │ CHOOSE UUID v7 IF:                   │
├──────────────────────────────────────┼──────────────────────────────────────┤
│ • Timestamps must remain private     │ • Identifiers are used as DB keys    │
│ • Pure randomness is required        │ • High-volume write performance      │
│ • Public API endpoints               │ • Time-sorting is beneficial         │
│ • Ephemeral session / token IDs      │ • Event streams, logs, and telemetry │
│ • Existing codebases built on v4     │ • Greenfield modern cloud apps       │
└──────────────────────────────────────┴──────────────────────────────────────┘

Both UUID v4 and UUID v7 are exceptional tools standardized under RFC 9562. By understanding the balance between randomness and time ordering, you can pick the perfect identifier strategy for your tech stack.

14. Frequently Asked Questions (FAQ)

Is UUID v7 better than UUID v4?

UUID v7 is generally better for database primary keys because its time-ordered structure minimizes B-Tree index fragmentation. However, UUID v4 is superior when you want pure randomness and do not want to expose creation timestamps.

Can UUID v7 replace UUID v4 completely?

No. UUID v4 will always remain essential for use cases where creation timestamps must remain confidential, such as public API identifiers, reset tokens, and security contexts.

Does UUID v7 expose the exact time it was created?

Yes. The first 48 bits of a UUID v7 represent the Unix epoch timestamp in milliseconds. Anyone can extract the exact creation date and millisecond from the identifier.

How do I tell if a UUID is v4 or v7?

Look at the 13th character (the first digit of the third group):

xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx is Version 4.
xxxxxxxx-xxxx-7xxx-xxxx-xxxxxxxxxxxx is Version 7.

Is UUID v7 supported in all programming languages?

Yes. Since the publication of RFC 9562 in 2024, official and community UUID v7 packages are available across JavaScript/TypeScript, Python, Go, Rust, Java, C# (.NET 9+), PHP, and Ruby.

15. Conclusion & Developer Tools

Whether your architecture demands the time-ordered efficiency of UUID v7 or the confidential randomness of UUID v4, you can generate and validate all your identifiers online:

UUID Generator — Generate instant UUID v4 and v7 identifiers.
GUID Generator — Create Microsoft and .NET compatible GUIDs.
UUID / GUID Validator — Validate formatting and extract version metadata.
Bulk UUID Generator — Create up to 10,000 UUIDs in batch.
Base64 UUID Generator — Compress 128-bit identifiers into compact 22-character strings.