UUID v7 Generator — Time-Ordered UUIDs for Database Primary Keys

UUID v4 is fully random — its 122 bits of entropy are great for uniqueness but terrible for database indexes. Every INSERT lands at a random spot in the B-tree, causing page splits and cache misses. UUID v7 (RFC 9562) puts a 48-bit Unix millisecond timestamp in the first bits, followed by 74 random bits. Result: values generated close in time are close in the sort order too — the index stays hot, INSERTs stay cheap.

Yes. UUID v7 was standardized in RFC 9562 (May 2024), which superseded RFC 4122 and introduced v6 / v7 / v8. Before that, teams used various homegrown formats (KSUID, ULID, Twitter Snowflake) to get the same time-ordering benefits. v7 is now the interoperable, standards-track answer.

Almost always yes, if UUID v7 support exists in your driver. Postgres 18 has native uuidv7(); before that, most driver libraries (uuid npm, uuid-utils in Python, uuidgen in Java) generate v7 already. In MySQL and SQL Server, use v7 UUIDs and store them BINARY(16) for locality. The write throughput / index bloat improvements over v4 are dramatic on large tables.

Yes — this tool does it in the table above. Take the first 12 hex chars (48 bits) of the UUID, parse as an integer, treat as Unix milliseconds. In code: `new Date(parseInt(uuid.replaceAll('-','').slice(0,12), 16))`. That's when the UUID was minted, useful for debugging and time-range queries without extra columns.

The random bits (74 of them) come from crypto.getRandomValues, a cryptographically secure PRNG. But you should NOT use UUID v7 as a security token — the timestamp is guessable and 74 bits of entropy is less than v4's 122. Use them for IDs you're happy publishing, not for password reset tokens or session cookies.