# UUIDv4 versus UUIDv7 key locality > Source-anchored research for UUIDv4 versus UUIDv7 key locality. Run status: COMPLETED. Parent: [Random-key (hashed/UUID) index insert behavior](https://llms-explorer.com/tree/random-key-hashed-uuid-index-insert-behavior/) · 4 facets · 14 facts · page: https://llms-explorer.com/tree/uuidv4-versus-uuidv7-key-locality/ ## How it works - Separate key-generation cost from index-maintenance cost and control run order and cache state. CST Solution found inline SQL v7 generation erased its pre-generated insertion advantage; equenum reports v7 slower when tested second and faster when tested first. Neither finding disproves timestamp locality. (medium confidence) — [source](https://cstsolution.com/blog/uuid-vs-bigint-primary-key/) - The pg_uuidv7 benchmark measures SELECT calls to UUID generators with pgbench, reporting near-equal native v4, extension v7, and native v7 generation throughput; because it does not insert indexed rows, those results do not measure the insertion-locality mechanism described by RFC 9562. (high confidence) — [source](https://github.com/fboulnois/pg_uuidv7/blob/main/BENCHMARKS.md) ## Measurements and reference values - The geckonz MongoDB experiment stores UUIDs as BSON Binary subtype 4 and configures a 2 GB WiredTiger cache with --syncdelay 0; its PostgreSQL configuration disables fsync, full_page_writes, and synchronous_commit, so the reported results need those configuration limits when used as evidence. (low confidence) (verified as of 2026-10-30) — [source](https://github.com/geckonz/uuid-perf-test) ## Comparisons and alternatives - UUIDv4 distributes successive keys across unrelated B-tree locations. UUIDv7 places a 48-bit millisecond timestamp first, so keys generated near the same time cluster in an index that compares their standard byte representation. This improves insertion locality rather than changing the UUID width. (high confidence) — [source](https://www.rfc-editor.org/rfc/rfc9562.html) - Schneider reported 375 seconds for UUIDv4 versus 290 seconds for UUIDv7 while adding one million rows to a 20-million-row PostgreSQL table with concurrent queries and 1 GB shared_buffers. This is historical evidence from a January 2024 development build plus a UUIDv7 patch, not a MongoDB performance ratio. (low confidence) — [source](https://ardentperf.com/2024/02/03/uuid-benchmark-war/) - The geckonz repository reports MongoDB 8 sample times of 1.66 versus 1.14 seconds for 10000 customer inserts and 1.73 versus 1.40 seconds for account inserts, v4 versus v7. It uses BSON Binary subtype 4, 5 million customers and 7 million accounts, a local Docker setup, --syncdelay 0 and a 2 GB WiredTiger cache. Treat these as author-reported observations, not independently reproduced production guarantees. (low confidence) (verified as of 2026-10-30) — [source](https://github.com/geckonz/uuid-perf-test) - An insert-locality advantage does not imply faster point reads or joins. In the same geckonz MongoDB sample, 100000 primary-key reads took 9.82 seconds with v4 and 10.52 with v7, and 50000 lookups took 10.87 versus 12.38 seconds. No uncertainty intervals establish whether these differences are significant. (low confidence) — [source](https://github.com/geckonz/uuid-perf-test) - CST Solution reports a PostgreSQL 16 bulk test where random-tail UUIDv7 produced a 40 MB index at 67.01% leaf density versus UUIDv4 at 38 MB and 72.31%. A synthetic one-millisecond-per-row v7 sequence reached 30 MB and 90.03%. This scopes the smaller-index claim to generator and ingestion pattern; it is not evidence that WiredTiger has identical split behavior. (low confidence) — [source](https://cstsolution.com/blog/uuid-vs-bigint-primary-key/) - RFC 9562 defines UUIDv4 with 122 random bits, whereas UUIDv7 puts a 48-bit big-endian Unix-millisecond timestamp first; both remain 128-bit identifiers, so UUIDv7 changes key ordering rather than key width. (low confidence) — [source](https://www.rfc-editor.org/rfc/rfc9562.html) - A 200,000-user SQLite experiment on a MacBook M4 Pro, using BLOB UUIDs, WAL mode, and 8192-byte pages, reports very little UUIDv4-versus-UUIDv7 difference; it also warns that mixed-CRUD results were noisy. (low confidence) — [source](https://lik.ai/blog/sqlite-primary-key-benchmarks/) - The benefit is workload dependent rather than an across-the-board acceleration: the SQLite experiment finds little v4/v7 difference, and the geckonz MongoDB sample reports faster v7 inserts but slightly slower v7 primary-key selections and account/customer lookups. (medium confidence) — [source](https://lik.ai/blog/sqlite-primary-key-benchmarks/) ## Facts and statements - Random-key inserts can expand the active index working set beyond cache. MongoDB documents increased WiredTiger eviction and disk updates for large random indexed inserts; Schneider observed UUIDv4 primary-key pages consuming buffer cache needed by other data in a PostgreSQL workload. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/method/db.collection.insertMany.md) - UUIDv7 does not inherently guarantee strict order within one millisecond: RFC 9562 permits random trailing bits and makes additional monotonicity constructs optional; delayed arrivals or clock changes also require care before assuming every insertion reaches the rightmost leaf. (medium confidence) — [source](https://www.rfc-editor.org/rfc/rfc9562.html) - Inference: UUIDv7 locality applies to an index on the ordered UUID value; hashing that field removes timestamp ordering from that hashed index. MongoDB documents hashed distribution of monotonic inputs. An ordinary _id index and a separate hashed shard-key index therefore need separate analysis. (medium confidence) — [source](https://www.rfc-editor.org/rfc/rfc9562.html)