What This Video Covers
This walkthrough explains UUID v7 from first principles — why it was created, how its bit layout differs from UUID v4, and what the timestamp prefix means for real-world applications.
Skill level: Beginner to intermediate Best for: Developers evaluating UUID v4 vs v7 for a new project
Key Concepts You Will Learn
1. The 128-bit structure of a UUID v7
A UUID v7 is 128 bits arranged as:
Bits 0–47: unix_ts_ms — Unix time in milliseconds (48 bits)
Bits 48–51: version — always 0111 = "7"
Bits 52–63: seq_hi — monotonic counter or random (12 bits)
Bits 64–65: variant — always 10
Bits 66–127: rand_b — cryptographically random (62 bits)
The timestamp occupies the entire first group plus the start of the second group in the standard xxxxxxxx-xxxx-7xxx-xxxx-xxxxxxxxxxxx format. See UUID Byte Layout for the annotated hex breakdown.
2. Why lexicographic sort equals chronological sort
Because the timestamp is stored big-endian at the front, string-comparing two UUID v7 values gives the same result as comparing their creation timestamps. This is why ORDER BY id on a UUID v7 primary key gives creation-time ordering — no separate created_at index required.
3. B-tree index behaviour
Database B-tree indexes work best when new values insert at the end — like auto-increment integers. UUID v4 inserts at random positions, causing page splits. UUID v7’s timestamp prefix ensures new values cluster at the rightmost leaf node, nearly matching auto-increment performance at scale.
4. The monotonic counter
When multiple UUIDs are generated within the same millisecond, a well-implemented generator increments a counter in bits 52–63 to maintain strict ordering. RFC 9562 §6.2 recommends this but does not require it. The uuid npm package implements a per-process counter; PostgreSQL 18’s uuidv7() does not.
5. When to choose v4 instead
UUID v7’s timestamp is readable — anyone with the ID knows roughly when a record was created. For externally visible identifiers like share links, tokens, or public API keys, use UUID v4 instead. For internal database primary keys, v7 is the better default. See the full decision guide at UUID v4 vs v7.
Related Reading
After watching this video, the natural next steps are:
- UUID Byte Layout — every bit in the 128-bit structure annotated
- Lexicographical Order — why string sort equals time sort
- Monotonic Counter — within-millisecond ordering in UUID v7
- UUID in Databases — PostgreSQL, MySQL, and index benchmarks
- UUID v4 vs v7 — full side-by-side comparison
- RFC 9562 — what changed from RFC 4122
Watch on YouTube
Search for UUID v7 explanation videos on YouTube ↗
Generate a UUID v7 Now
After learning how UUID v7 works, try it: generate a UUID v7 in the browser and inspect the timestamp prefix live — or use the UUID Decoder to extract the embedded timestamp from any UUID v7 string.
Frequently asked questions
What is the best way to learn how UUID v7 works?
Start with the bit layout: UUID v7 puts a 48-bit Unix millisecond timestamp in the leading bits, followed by a 4-bit version (7), a 12-bit monotonic counter, the 2-bit variant, and 62 random bits. The timestamp at the front is why v7 sorts chronologically as a plain string — key to B-tree performance. See the UUID Byte Layout guide and the UUID v7 Explained walkthrough.
Should I use v4 or v7?
Use v7 for database primary keys (time-sortable, index-friendly) and v4 for anything where creation order could leak information, like tokens or share links.
How many bits does a UUID have?
A UUID is exactly 128 bits (16 bytes). In the standard hyphenated string format, 4 bits are used for the version field (position 13) and 2 bits for the variant (high 2 bits of position 17), leaving 122 bits for version-specific data. UUID v4 uses all 122 bits for randomness; UUID v7 uses 48 bits for a Unix millisecond timestamp and 74 bits for a monotonic counter and randomness. See RFC 9562 §4.
What is UUID v7 and how does it differ from v4?
UUID v7 embeds a 48-bit Unix millisecond timestamp in its leading bits, making values generated later sort after values generated earlier — both lexicographically and numerically. UUID v4 uses all 122 bits for randomness with no timestamp. This difference makes v7 preferable for database primary keys where B-tree index performance matters. See UUID v4 vs v7 — full comparison.
Why does UUID v7 sort chronologically as a plain string?
The 48-bit Unix millisecond timestamp occupies the first 12 hex characters of the UUID string. Because the timestamp is stored big-endian (most significant byte first), alphabetical string comparison of two UUID v7 values produces the same ordering as comparing the timestamps numerically. This is the core insight behind v7's B-tree friendliness — see Lexicographical Order and UUID Byte Layout for the bit-level detail.