I am a contributor to RFC 9562, and I wrote this FAQ because I kept seeing the same concerns about UUIDv7 surfacing across Hacker News, Reddit, and developer blogs. The discussion would always circle back to the same objections, most of which are superficial and fall apart when you look closer. UUIDv7 is too big. The timestamp leaks creation time. It creates hot shards. It’s slower than BIGINT. Sorting breaks if clocks drift. After encountering these objections repeatedly, I decided to collect the most debated questions in one place and answer them based on real implementation experience.
The result is a UUIDv7 and RFC 9562 FAQ organised by topic. The sections are thematic, but within each section I ordered the questions from the most important and most discussed down to the finer points that only arise under extreme throughput or edge conditions. That way you can read the first few questions of a section and already cover the arguments you are most likely to encounter.
The Choosing UUIDv7 section opens with a strong recommendation. For new projects, UUIDv7 should be the default primary key. UUIDv7 delivers lookup and write performance equivalent to BIGINT while enabling globally unique IDs that can be generated on client or server. It overcomes the classic shortcomings of auto-increment: the need for coordination, key collisions when merging data, incorrect joins, revealing the total number of records, and making brute-forcing valid keys easy.
UUIDv7 uses exactly twice the storage of BIGINT (16 vs 8 bytes) for the column itself and for every index and foreign key that references it. However, the overall database size does not double because other fields remain unchanged, and each row already has a fixed overhead. In many cases, the date and time extracted from the UUIDv7 can be used instead of the created_at column, but with caution.
One practical topic that gets a lot of attention is compact encoding. Many people reach for ULID to get a shorter string, but the FAQ describes Base62id, an encoding that compresses any 128-bit UUID into 22 URL-safe alphanumeric characters. That is about 40 percent shorter than the classic hex-and-dash format. With UUIDv7 it even preserves time-based sort order under a binary-safe collation. So you get the compactness without adopting a different identifier standard.
The privacy concern about timestamps also gets a clean solution. For centralised UUIDv7 generation, instead of exposing the real creation time, an implementation can apply a hopping timestamp offset that makes the upper bits meaningless to an outsider while keeping sort order intact within each offset interval. That technique removes most of the anxiety around exposing UUIDv7 in public APIs.
The migration section demonstrates that moving from UUIDv4 to UUIDv7 is painless because both are 128-bit and can coexist in the same column. Migrating from BIGINT with zero downtime is laid out step by step.
A generation rate benchmark tells you almost nothing. Generating a UUIDv7 with a fast entropy source is extremely fast compared to the time the database needs to insert or update a row. You need to measure multi-threaded inserts and subsequent JOIN queries under your own row sizes and hardware.
Beyond these highlights, the FAQ digs into a wide range of other questions that fuel heated discussions and offers practical solutions that solve real problems. I made sure the FAQ does not oversell UUIDv7. It just insists on fair comparisons. If you have ever hesitated to adopt UUIDv7 because of something you read in a comment section, this guide will probably clear up your doubts. It is the reference I wish I could have pointed people to a year ago.
You can read the full UUIDv7 and RFC 9562 FAQ here: https://github.com/sergeyprokhorenko/RFC-9562-FAQ/blob/main/README.md