What is UUID Version 7?

UUID version 7 is the newest UUID standard, defined in RFC 9562 (published May 2024). It combines a Unix timestamp in milliseconds with cryptographically secure random data, creating UUIDs that are both globally unique and naturally time-sortable.

Unlike UUID v1 which uses an obscure Gregorian timestamp and exposes MAC addresses, UUID v7 uses the familiar Unix epoch (January 1, 1970) and keeps the random bits truly random—no hardware information is leaked.

UUID v7 is becoming the recommended choice for database primary keys in new applications because the time-ordered nature means consecutive IDs cluster together, dramatically improving B-tree index performance compared to random UUID v4.

Key Advantages of UUID v7

• Time-sortable: Lexicographic sorting = chronological order
• Database optimized: Sequential-ish inserts reduce index fragmentation
• Privacy-safe: No MAC address or hardware information exposed
• Unix timestamp: Familiar epoch, easy to extract and convert
• Millisecond precision: Good enough for most use cases
• RFC 9562 compliant: Official IETF standard (2024)

UUID v7 Structure

UUID v7 places the timestamp at the most significant bits, making it lexicographically sortable:


                    unix_ts_ms-unix_ts_ms-7xxx-yxxx-random

                    xxxxxxxx-xxxx-7xxx-yxxx-xxxxxxxxxxxx


                    48 bits  4 bits  12 bits  2+62 bits

Field	Bits	Description
unix_ts_ms	48	Unix timestamp in milliseconds (first 48 bits)
ver	4	Version bits (always "0111" = 7)
rand_a	12	Random bits (or sub-millisecond precision)
var	2	Variant bits (always "10")
rand_b	62	Random bits

Example UUID v7: 018f4360-7a70-7c5e-bcd5-1a2b3c4d5e6f

The 13th character is always "7" for UUID v7.

Why UUID v7 is Better for Databases

The main problem with UUID v4 in databases is index fragmentation. Random UUIDs get inserted at random positions in B-tree indexes, causing page splits and poor cache locality.

UUID v4 (Random)

• New records inserted randomly across index
• Causes B-tree page splits
• Poor cache hit rate
• Higher write amplification
• Index bloat over time

UUID v7 (Time-sorted)

• New records append to end of index
• Minimal page splits
• Excellent cache locality
• Lower write amplification
• Compact, efficient indexes

📊 Performance Impact

In benchmarks, UUID v7 can provide 2-10x faster insert performance compared to UUID v4 on large tables with B-tree indexes. The exact improvement depends on your database, index configuration, and write patterns. For PostgreSQL and MySQL, the difference is most noticeable at scale (millions+ rows).

UUID v7 vs v1 vs v4: Comparison

Feature	UUID v7	UUID v4	UUID v1
Standard	RFC 9562 (2024)	RFC 4122 (2005)	RFC 4122 (2005)
Time-Sortable	✓ Yes (lexicographic)	✗ No	~ Partial
Timestamp Epoch	Unix (1970)	N/A	Gregorian (1582)
Time Precision	Milliseconds	N/A	100 nanoseconds
Privacy	✓ Good	✓ Excellent	✗ Exposes MAC
DB Index Performance	✓ Excellent	✗ Poor	~ Good
Language Support	Growing	Universal	Good
Random Bits	74 bits	122 bits	14 bits

💡 Recommendation

For new projects: Use UUID v7 for database primary keys. It combines the best of both worlds—global uniqueness like v4, plus time-ordering for database performance. Use UUID v4 for security tokens where unpredictability is more important than sorting.

When to Use UUID v7

Ideal Use Cases

• Database primary keys: Best choice for new applications
• Event sourcing: Natural chronological ordering
• Distributed systems: Time-ordered without coordination
• Log entries: Sortable correlation IDs
• Message queues: Ordered message identifiers
• Audit trails: Built-in timestamp

Consider Alternatives

• Security tokens: Use UUID v4 for maximum unpredictability
• Legacy systems: May require v1 or v4 specifically
• Deterministic IDs: Use UUID v5
• Privacy-critical: Timestamp reveals creation time

Generate UUID v7 in Code

UUID v7 support is growing rapidly. Here's how to generate them in popular languages:

JavaScript/TypeScript (uuid package v9+) Full guide →

import { v7 as uuidv7 } from 'uuid';

// Generate UUID v7
const id = uuidv7();
console.log(id);  // e.g., "018f4360-7a70-7c5e-bcd5-1a2b3c4d5e6f"

// Multiple UUIDs generated in same millisecond are still unique
// due to random component

Python (uuid7 package) Full guide →

# pip install uuid7
from uuid_extensions import uuid7

# Generate UUID v7
id = uuid7()
print(id)  # e.g., 018f4360-7a70-7c5e-bcd5-1a2b3c4d5e6f

# Extract timestamp (returns datetime)
from uuid_extensions import uuid7_time
timestamp = uuid7_time(id)
print(timestamp)  # 2024-05-20 15:30:45.123000

Go (google/uuid v1.6+) Full guide →

import "github.com/google/uuid"

// Generate UUID v7
id, err := uuid.NewV7()
if err != nil {
    log.Fatal(err)
}
fmt.Println(id.String())  // e.g., "018f4360-7a70-7c5e-bcd5-1a2b3c4d5e6f"

// Get timestamp from UUID v7
timestamp, ok := id.GetTime()

Rust (uuid crate v1.7+) Full guide →

use uuid::Uuid;

// Generate UUID v7
let id = Uuid::now_v7();
println!("{}", id);  // e.g., "018f4360-7a70-7c5e-bcd5-1a2b3c4d5e6f"

// Get timestamp
let (seconds, nanos) = id.get_timestamp()
    .expect("UUID v7 has timestamp")
    .to_unix();

More guides: Java, C#, PHP, Ruby.

UUID v7 in Databases

Most databases don't have native UUID v7 support yet, so you'll typically generate them in your application code:

PostgreSQL Full guide →

-- Store as native UUID type (works perfectly with v7)
CREATE TABLE events (
    id UUID PRIMARY KEY,  -- Generated by application
    event_type VARCHAR(50),
    created_at TIMESTAMP DEFAULT NOW()
);

-- UUID v7 naturally sorts by time!
SELECT * FROM events ORDER BY id;  -- Chronological order

-- Future: PostgreSQL may add uuid_generate_v7() function

MySQL Full guide →

-- Store as BINARY(16) for best performance
CREATE TABLE events (
    id BINARY(16) PRIMARY KEY,
    event_type VARCHAR(50),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Insert application-generated UUID v7
INSERT INTO events (id, event_type) 
VALUES (UUID_TO_BIN('018f4360-7a70-7c5e-bcd5-1a2b3c4d5e6f'), 'click');

-- UUID v7 gives you time-sorted results!
SELECT BIN_TO_UUID(id), event_type FROM events ORDER BY id;

Extracting Timestamp from UUID v7

One of UUID v7's advantages is easy timestamp extraction. The first 48 bits are the Unix millisecond timestamp:

JavaScript

function extractTimestamp(uuidv7) {
    // Remove hyphens and take first 12 hex chars (48 bits)
    const hex = uuidv7.replace(/-/g, '').substring(0, 12);
    const timestamp = parseInt(hex, 16);
    return new Date(timestamp);
}

const uuid = '018f4360-7a70-7c5e-bcd5-1a2b3c4d5e6f';
console.log(extractTimestamp(uuid));  // 2024-05-20T15:30:45.123Z

Use our UUID Decoder tool to automatically extract timestamps from UUID v7 (and v1).

Related UUID Tools

UUID v4 Random UUID v1 Timestamp UUID Decoder Extract Timestamp Bulk Generator Up to 10,000

Frequently Asked Questions

Is UUID v7 widely supported?

Support is growing rapidly since RFC 9562 was published in May 2024. Major UUID libraries in JavaScript, Go, Rust, and Python now support v7. Database native support is still limited, but application-generated UUIDs work fine.

How unique are UUID v7s generated in the same millisecond?

Very unique. While the timestamp is the same, UUID v7 has 74 random bits (more than enough for uniqueness). Even generating millions of UUIDs in the same millisecond, collisions are astronomically unlikely. Some implementations also use monotonic counters for sub-millisecond ordering.

Should I migrate from UUID v4 to v7?

For existing systems, probably not worth the migration effort unless you're experiencing index performance issues. For new tables or projects, UUID v7 is the better default choice. You can also use both—v7 for database PKs, v4 for security tokens.

Does UUID v7 expose when something was created?

Yes, the embedded timestamp can be extracted. If creation time is sensitive information, consider UUID v4 instead. However, for most applications, exposing creation time isn't a concern—and you probably have a created_at column anyway.

UUID v7 Generator