UUID v4 vs UUID v7: Understanding the Future of Unique Identifiers

If you’ve worked with databases, APIs, microservices, or distributed systems, you’ve probably encountered UUIDs.

For years, UUID v4 has been the go-to choice for generating unique identifiers. But a newer version -UUID v7 -is quickly becoming the preferred option for modern applications.

In this article, we’ll explore:

• What UUIDs are
• How UUID v4 works
• What makes UUID v7 different
• UUID v4 vs UUID v7 comparison
• Database performance implications
• When to use each version
• .NET code examples

What Is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit value used to uniquely identify objects across systems without requiring a centralized ID generator.

A typical UUID looks like this:

550e8400-e29b-41d4-a716-446655440000

The probability of generating duplicate UUIDs is extremely small, making them ideal for:

• Database primary keys
• Microservices
• Event-driven systems
• Distributed applications
• APIs

UUIDs are standardized by the IETF. The latest specification is RFC 9562, which defines newer UUID versions including UUID v7.

UUID v4: The Traditional Choice

UUID v4 is based almost entirely on random numbers.

Example:

c53b7b57-0db1-4a38-aec1-d32cf98a5e0f

Characteristics:

✅ Extremely easy to generate

✅ No central authority required

✅ Very low collision probability

✅ Supported everywhere

❌ No ordering information

❌ Poor database index locality

❌ Causes index fragmentation in large tables

Generating UUID v4 in .NET

Guid id = Guid.NewGuid();

Console.WriteLine(id);

Output:

3f7d44e7-b78d-4db0-bcf5-4e4ccbc73a0c

Simple and effective.

But there’s a hidden problem.

The Database Problem with UUID v4

Imagine a table with millions of rows:

CREATE TABLE Orders
(
    Id UNIQUEIDENTIFIER PRIMARY KEY,
    OrderDate DATETIME2
);

Every new UUID v4 is random.

That means inserts happen at random locations inside the index.

The database constantly performs:

• Page splits
• Index rebalancing
• Additional disk writes

As the table grows, performance can degrade significantly.

This issue becomes more visible in:

• SQL Server
• PostgreSQL
• MySQL
• Distributed databases

This is one of the main reasons UUID v7 was introduced.

What Is UUID v7?

UUID v7 combines:

• Unix timestamp (milliseconds)
• Random entropy

The first portion contains a timestamp while the remaining bits preserve randomness and uniqueness. RFC 9562 defines UUID v7 as a time-ordered UUID derived from the Unix epoch timestamp.

Example:

01975d93-cf35-7e24-a8cb-2b0fd4f0d2fa

Unlike UUID v4, UUID v7 values are generated in chronological order.

This means newer IDs naturally sort after older IDs.

UUID v7 Structure

Simplified layout:

+-----------------------+
| Timestamp (48 bits)   |
+-----------------------+
| Version (7)           |
+-----------------------+
| Random Bits           |
+-----------------------+

UUID v7 contains:

• 48-bit Unix timestamp
• Version field set to 7
• Random data for uniqueness

This creates IDs that are:

• Globally unique
• Time sortable
• Database friendly

RFC 9562 specifies a 48-bit Unix timestamp in milliseconds followed by version and randomness fields.

UUID v4 vs UUID v7

FeatureUUID v4UUID v7UniquenessExcellentExcellentRandomnessFully RandomMostly RandomSortableNoYesContains TimestampNoYesDatabase PerformanceModerateBetterIndex FragmentationHigherLowerDistributed SystemsGoodExcellentModern RecommendationLegacy DefaultPreferred

Why UUID v7 Improves Database Performance

Consider inserting these UUID v4 values:

A1F3...
2B91...
F9C8...
0A22...

The order is random.

Now consider UUID v7:

01975d93...
01975d94...
01975d95...
01975d96...

These IDs are naturally ordered by creation time.

Benefits:

• Sequential inserts
• Fewer page splits
• Better index locality
• Faster range queries
• Improved storage efficiency

UUID v7 was specifically designed to improve ordering and indexing characteristics while maintaining strong uniqueness guarantees.

Generating UUID v7 in .NET

Starting with newer libraries and ecosystem support, UUID v7 generation is becoming widely available.

Example:

Guid guid = Guid.CreateVersion7();

Console.WriteLine(guid);

Output:

01975d93-cf35-7e24-a8cb-2b0fd4f0d2fa

Notice how IDs generated later sort after earlier ones.

This makes them ideal for:

• Event sourcing
• Audit logs
• Order systems
• Distributed services

When Should You Use UUID v4?

Choose UUID v4 when:

• Ordering does not matter
• Existing systems already use v4
• Simplicity is more important
• Database scale is relatively small

Examples:

• Session IDs
• Temporary tokens
• Small applications
• Legacy platforms

When Should You Use UUID v7?

Choose UUID v7 when:

• Building new systems
• Designing microservices
• Creating high-scale databases
• Using event-driven architectures
• Optimizing database performance

Examples:

• Orders
• Payments
• Events
• Logs
• User activity streams
• Distributed systems

Many architects now consider UUID v7 the best default choice for new applications because it combines uniqueness, privacy, and time ordering.

Migration Strategy

If your application currently uses UUID v4:

1. Keep existing records unchanged.
2. Generate UUID v7 for new records.
3. Test indexing performance.
4. Monitor insert throughput.

A full migration is usually unnecessary.

Many organizations simply adopt UUID v7 for future entities.

Final Thoughts

UUID v4 served the software industry well for nearly two decades.

However, modern distributed systems demand more than uniqueness. We also care about:

• Database performance
• Index efficiency
• Time-based ordering
• Scalability

UUID v7 delivers all of these benefits while preserving the simplicity and global uniqueness that made UUIDs popular in the first place.

If you’re starting a new .NET application today, UUID v7 is likely the better default choice.

In short:

• Use UUID v4 when you only need uniqueness.
• Use UUID v7 when you need uniqueness plus performance and ordering.

For most modern applications, UUID v7 is the future.