September 24, 2026
UUID v4 vs. v7: Why Time-Ordered UUIDs Are Taking Over
UUIDv4 is generated from 122 bits of pure randomness, so consecutive IDs have no relationship to each other and no ordering. UUIDv7, finalized in RFC 9562, replaces the leading bits with a millisecond-precision timestamp, so IDs generated close together in time sort close together — which matters a lot more for database performance than it sounds.

Why random IDs hurt database indexes
Most databases store rows in index order on disk (or close to it, for a clustered/primary-key index). When new IDs are fully random, as UUIDv4 always are, each insert lands at a random point in the existing index rather than at the end — forcing the database to constantly rebalance B-tree pages instead of just appending. At high insert volume, this measurably degrades write throughput and bloats the index with fragmented, half-empty pages.
What UUIDv7 changes
A UUIDv7 starts with a 48-bit Unix timestamp in milliseconds, followed by random bits for the rest. Two UUIDv7s generated a second apart will sort in that same order as plain byte comparisons — which is exactly how most databases compare index keys. New rows land at (or near) the end of the index again, the same access pattern as a traditional auto-incrementing integer ID, while still keeping the collision-resistance and decentralized generation that made UUIDs attractive over auto-increment in the first place.
When to actually use v7 over v4
- Use v7 when the UUID is a primary key or is indexed, and rows are inserted at meaningful volume — this is where the sequential-insert benefit actually shows up
- Use v7 when you want IDs that are naturally sortable by creation time without a separate created_at query
- Stick with v4 when the ID isn't the primary index key, or when you specifically don't want the ID to leak any information about when it was created — v7's embedded timestamp is technically extractable
- Both are equally safe against collisions in practice; the difference is purely about index locality and information leakage, not uniqueness
They look almost identical
A v4 and v7 UUID are both 36 characters in the standard 8-4-4-4-12 hyphenated format, and the version is only visible in one nibble (the first character of the third group: 4xxx for v4, 7xxx for v7). If you're auditing an existing system's ID scheme, that single character is the tell.
Want to try this yourself?
Open UUID Generator →