Home/UUID v7 Generator
TIME-ORDERED · RFC 9562 · MODERN STANDARD
UUID v7 Generator
Generate time-ordered UUID v7 identifiers instantly — the modern standard for database primary keys, combining a Unix millisecond timestamp with random bits. Free, browser-only, no signup.
★ 100% Free🔒 Zero Server Calls✓ RFC 9562 Compliant
What Is It
UUID v7 Generator: What Is a UUID v7?
This UUID v7 generator produces the time-ordered UUID variant formally added in RFC 9562 (May 2024). Its first 48 bits encode the current Unix timestamp in milliseconds, and the remaining bits are filled with random data — providing a very low collision probability and identifiers that are broadly sortable by creation time.
This makes UUID v7 a useful choice for many new database primary keys: rows generally insert in roughly chronological order, which can reduce B-tree index fragmentation compared with random UUID v4 keys at scale.
Anatomy
UUID v7 Format
A UUID v7 follows the standard 8-4-4-4-12 pattern, but the first 12 hex characters are not random — they directly encode a timestamp:
| Position | Value | Meaning |
|---|---|---|
| First 48 bits (12 hex chars) | Timestamp | Unix time in milliseconds |
| 15th character (13th hex digit) | 7 | Always the digit 7 — marks this as version 7 |
| 20th character (17th hex digit) | 8, 9, a, or b | Variant bits (RFC 9562 variant) |
| Remaining bits | Random hex | ~74 bits of randomness |
Example: 018f7a3c-1b2d-7e4f-a3c2-1234567890ab — the first section changes predictably over time, unlike v4.
Why It Matters
Why UUID v7 Is Replacing v4 for Database Keys
✅
The core problem UUID v7 solves
B-tree indexes (used by PostgreSQL, MySQL, and most databases) perform best when new rows insert in roughly ascending order. Random UUID v4 keys scatter inserts across the entire index, causing page splits and bloat. UUID v7's timestamp prefix keeps new rows clustered together — matching the index performance of an auto-increment column while keeping UUID's distributed-generation benefits.
| UUID v4 | UUID v7 | |
|---|---|---|
| Sortable by time | No | Yes |
| Index performance at scale | Degrades (random inserts) | Often more efficient (roughly time-ordered inserts) |
| Reveals creation time | No | Yes — by design |
| Best for | Opaque identifiers; unpredictable random IDs | Database primary keys |
Code
Generate a UUID v7 in Code
PostgreSQL 18+
SELECT uuidv7();
CREATE TABLE events (
id UUID PRIMARY KEY DEFAULT uuidv7(),
payload JSONB
);
Python (uuid6 package)
from uuid6 import uuid7
id = uuid7()
Java (JUG library)
import com.fasterxml.uuid.Generators;
UUID id = Generators.timeBasedEpochGenerator().generate();
Rust (uuid crate v1.4+)
let id = Uuid::now_v7();
Need more languages? See our full code guides for JavaScript, PHP, Go, and more.
FAQ
UUID v7 FAQ
UUID v7 embeds the creation timestamp, which means anyone who sees the ID can determine roughly when it was created. This is not a security flaw, but if you specifically need to hide creation time (for example, to prevent users from guessing how many records exist), use UUID v4 instead.
PostgreSQL 18 (released September 2025) added native uuidv7() support. For older PostgreSQL versions, MySQL, or other databases without native support, generate the UUID v7 value in your application code and insert it as a regular UUID/CHAR column value.
It is extremely unlikely. Even though the timestamp portion is identical for UUIDs generated in the same millisecond, roughly 74 bits of random data still follow it, providing 2^74 possible random combinations per millisecond. Collisions remain possible but are extremely unlikely with a well-implemented generator.
For existing tables with significant data, a full migration is rarely worth the disruption. Most teams simply switch new tables or new records going forward to UUID v7, leaving historical v4 keys untouched, since both formats coexist fine in the same database.