UUID v7 Generator
Generate time-ordered UUID v7 values. Embeds a Unix millisecond timestamp in the most significant bits so UUIDs sort chronologically - ideal for database primary keys.
What is UUID v7?
UUID v7 is the modern time-ordered UUID format defined in RFC 9562 (2024). It places a 48-bit Unix millisecond timestamp in the most significant bits of the UUID, followed by a 4-bit version field, 12 bits of random data (rand_a), the 2-bit variant, and 62 bits of random data (rand_b).
Because the timestamp occupies the high bits, v7 UUIDs generated at different times sort lexicographically in chronological order - the same way auto-increment integers do. This property is critically important for B-tree database indexes: sequential inserts fill index pages efficiently, avoiding the costly page splits and random I/O that random UUIDs (v4) cause at scale.
UUID v7 Bit Layout
| Bits | Field | Description |
|---|---|---|
| 0-47 | unix_ts_ms | Unix timestamp in milliseconds (48 bits, ~8,900 years range) |
| 48-51 | ver | Version = 0111 (7) |
| 52-63 | rand_a | 12 bits of random data (or monotonic counter per RFC 9562 ยง6.2) |
| 64-65 | var | Variant = 10 (RFC 4122 / RFC 9562) |
| 66-127 | rand_b | 62 bits of cryptographically random data |
RFC 9562 also defines an optional monotonic counter in rand_a to preserve ordering within the same millisecond. This generator uses fully random bits in rand_a, which is correct and simpler for most use cases.
Database Performance Impact
The performance difference between random UUIDs (v4) and time-ordered UUIDs (v7) as primary keys becomes significant at millions of rows:
UUID v4 - Random (problematic at scale)
- - New rows insert into arbitrary positions in the B-tree index
- - Index pages fill non-sequentially, causing frequent page splits
- - Working set of "hot" pages is large - poor buffer pool efficiency
- - Causes significant write amplification and fragmentation
UUID v7 - Time-ordered (optimal)
- + New rows always append to the rightmost leaf page
- + Index pages fill sequentially, minimising splits
- + Only the last few leaf pages need to stay in buffer pool
- + Same write patterns as auto-increment integers
Database Support
PostgreSQL
Store as uuid type. PostgreSQL 17+ includes uuidv7() natively. Earlier versions can use the pg_uuidv7 extension or generate in application code.
MySQL / MariaDB
Store as BINARY(16) (most efficient) or VARCHAR(36). InnoDB's clustered index benefits most from sequential UUID insertion order.
SQLite
Store as TEXT or BLOB. UUID v7 strings sort correctly as TEXT because the timestamp is in the high bits of the canonical form.
UUID v7 vs. ULID vs. Snowflake
UUID v7 is one of several time-ordered ID formats. The key differentiators:
- UUID v7 vs ULID: Both are 128-bit time-ordered. UUID v7 is an IETF standard; ULID is community-specified. UUID v7 uses standard UUID representation (hex + hyphens); ULID uses Crockford Base32. UUID v7 has native support in more databases and ORMs.
- UUID v7 vs Snowflake: Snowflake IDs are 64-bit (half the size) and require a centralised node/worker ID assignment to ensure uniqueness across machines. UUID v7 is fully decentralised - any node generates without coordination.
- UUID v7 vs UUID v1: Both are time-based, but v1 splits the timestamp across three fields to maintain the historical byte layout, making v1 strings not lexicographically sortable. UUID v7 places the full timestamp in the most significant bits for correct string-sort order.