Should you use sequential UUIDs?
October 2, 2026 · 14 min read
Database teams often debate whether primary keys should be sequential (time-ordered leading bytes) or random (UUID v4). The answer is not universal: sequential identifiers improve B-tree locality and insert throughput on monotonic indexes, while random IDs spread writes across the index and resist guessing. Modern RFC 4122 UUID version 7 and ULID give you sortable keys without abandoning standard 128-bit identity.
What makes a UUID sequential
A sequential UUID encodes a timestamp in the most significant bits so newly generated values sort after older ones in lexicographic and binary order. UUID v7 does this within the RFC family; ULID uses Crockford Base32 with a 48-bit time component. Random UUID v4 has no time structure - each new key lands in a random place in the index tree.
Sequential does not mean guessable in the sense of integers 1, 2, 3. The remaining random bits still provide entropy; attackers cannot enumerate your user table by incrementing an ID unless you actually use auto-increment integers.
Better clustering and insert performance
- B-tree locality - New rows append near the right edge of the index instead of scattering random leaf pages.
- Cache behavior - Hot pages stay in buffer pool longer for time-range queries on _id.
- Replication - Secondary indexes on time-correlated UUIDs can reduce write amplification vs pure v4 at extreme insert rates.
The win matters most on large InnoDB, PostgreSQL, or MongoDB collections with UUID-typed primary keys and high sustained insert QPS. Small apps with thousands of rows rarely measure the difference - choose standards and operability first.
When random UUID v4 still wins
Random v4 maximizes unpredictability of identifiers exposed in URLs or APIs. It avoids leaking creation order to competitors or users browsing IDs. If your bottleneck is not index fragmentation but preventing enumeration attacks, v4 or opaque tokens remain appropriate.
Some teams mistakenly call v4 “more secure” while ignoring that v7 still has 74+ bits of randomness in the spec layout - sufficient for unpredictability in public IDs when combined with authorization checks.
Security vs performance framing
Predictable order is not authentication. Never expose sensitive operations because “they would need to guess a UUID.” Always enforce authz on every request. Sequential IDs can hint that account A was created before account B; if that metadata is sensitive, use random IDs or internal surrogate keys separate from public URLs.
Practical decision guide
- High-volume inserts on UUID primary keys → prefer UUID v7 or ULID.
- Public IDs must not reveal chronology → UUID v4 or NanoID.
- MongoDB with binary subtype 04 → generate v7 client-side, store as BSON UUID.
- Legacy int auto-increment → migrate to v7 for UUID columns without sacrificing sort.
Generate and inspect v4 vs v7 output with the UUID generator and validate version bits with the UUID validator before rolling a migration.
FAQ
- Is UUID v7 sequential enough for databases?
- Yes. v7 is designed for time-ordered UUIDs compatible with RFC 4122 ecosystems.
- Does sequential UUID remove the need for indexes?
- No. You still index _id; sequential keys change how inserts hit the B-tree, not whether you need indexes.
- ULID or UUID v7?
- v7 when you need RFC tooling everywhere; ULID when you want 26-char Base32 strings and accept non-RFC encoding.
Related: UUID v1, v4, v7 explained · UUID performance in databases · ULID vs UUID