Why UUID v7
UUID version 7, standardized in RFC 9562 in 2024, puts a 48-bit Unix timestamp in milliseconds at the front of the ID and fills the rest with random bits. Because new IDs sort after older ones, they are added at the end of a B-tree index instead of at random positions. That keeps indexes compact and inserts fast, which is the main reason teams move from v4 to v7 for primary keys.
Each v7 UUID still carries 74 random bits, so collisions within the same millisecond are not a practical concern.
Things to know
- The timestamp is readable by anyone. If creation time is sensitive, use v4.
- v7 values fit any column that stores UUIDs, such as PostgreSQL’s uuid type.
- IDs created within the same millisecond are not guaranteed to be in order.
Frequently asked questions
Can I mix v4 and v7 in the same column?
Yes, they share the same format. Only the v7 values will sort by time.
How do I read the timestamp from a v7 UUID?
Take the first 12 hex digits, ignoring hyphens, and convert them from hex to a number. That is the creation time in milliseconds since 1970.