UUID v7 Generator

For years, engineering teams that wanted the collision-resistance of a UUID but the index-friendly ordering of a sequential integer had to build their own non-standard hybrid — commonly prefixing a random UUID with a manually generated timestamp, an approach used in various forms by several well-known distributed-systems companies before any official standard existed for it. RFC 9562 formalised that pattern into an official UUID version specifically so implementations across different languages and databases could produce and recognise the same time-ordered structure without every team independently reinventing a slightly different, incompatible variant of the same idea.

The leading 48 bits of a v7 UUID encode a Unix timestamp in milliseconds, which is what gives the value its sort order — comparing two v7 UUIDs as plain strings correctly reflects which was generated first, since the timestamp portion dominates the comparison. The remaining bits stay filled with cryptographically random data, exactly as in v4, so the value is just as resistant to guessing as a fully random UUID would be; only its ordering behaviour changes, not its unpredictability.

Beyond raw insert speed, a time-ordered primary key has a second practical benefit that matters day to day: rows naturally come back in creation order from a simple `ORDER BY id` query, without needing a separate `created_at` column and an extra index on it just to sort records chronologically. For a table that is frequently queried "most recent first" — an activity log, a queue, an audit trail — a v7 primary key gives that ordering for free as a side effect of the ID itself, rather than as a separate cost to maintain.