# Random-key (hashed/UUID) index insert behavior > Source-anchored research for Random-key (hashed/UUID) index insert behavior. Run status: COMPLETED. Parent: [MongoDB Wildcard and Hidden Indexes, Index Builds and Index Overhead](https://llms-explorer.com/tree/mongodb-wildcard-and-hidden-indexes-index-builds-and-index-overhead/) · 5 facets · 12 facts · page: https://llms-explorer.com/tree/random-key-hashed-uuid-index-insert-behavior/ ## How it works - MongoDB says a hashed index stores hashes of indexed values and describes hashed sharding as useful for monotonically increasing fields such as ObjectId or timestamps, because ranged sharding sends most new writes to one shard. Its random-data insert guidance also names hashed indexes as an example of random index entries. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-hashed/) - MongoDB clustered collections store documents in clustered-key order; the manual recommends sequentially increasing keys for insert performance and warns that random keys may reduce it. In a separate JSONBench experiment labeled 2025-02-19, UUIDv4 used more CPU and read I/O than UUIDv7 when MongoDB clustered documents by _id, while the comparable non-clustered UUIDv4 run had CPU use similar to UUIDv7 and default ObjectId. This points to physical document placement as a material workload condition. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/clustered-collections/) - A May 2021 MessageBird operations presentation reports that random UUID inserts into a unique secondary index caused more index regions to be loaded, leaving less memory for date-range indexes. The presentation describes a MySQL workload, so it corroborates the general locality mechanism but does not measure MongoDB. (low confidence) — [source](https://www.percona.com/sites/default/files/presentations/How%20to%20cope%20with%20%28unexpected%29%20mullipling%20of%20your%20workload.pdf) - The cache-residency qualification also appears in independent material. Percona's MongoDB storage article says user-supplied random _id inserts are fast while the _id index fits in memory and may need disk access when it does not. MariaDB's UUID guide describes random UUID inserts jumping among index positions and makes cache capacity central to its model; its throughput-specific estimates are cross-engine evidence, not MongoDB measurements. (medium confidence) — [source](https://www.percona.com/blog/the-effects-of-database-heap-storage-choices-in-mongodb/) ## Measurements and reference values - One self-published MongoDB UUID benchmark reports UUIDv7 insert speedups of 1.46x and 1.24x over UUIDv4 for two 10,000-document insert tests; its UUIDv7 primary-key point lookup was slightly slower at 0.93x. The benchmark used local Docker settings with fsync disabled and syncdelay set to zero, so these are workload-specific results. (low confidence) — [source](https://github.com/geckonz/uuid-perf-test) - In its September 14, 2026 SQLite experiment with 200,000 TEXT primary keys, DevToolLab reports UUIDv7 inserts 1.6–2.3x faster across four runs but the database file about 1% larger than with UUIDv4. This shows that insert locality and index-size gains are separate claims, and the size result does not transfer directly to MongoDB’s BSON binary indexes. (low confidence) — [source](https://devtoollab.com/blog/uuidv7-vs-uuidv4) ## Problems, failure modes and limitations - MongoDB warns that large bulk inserts of random values on an indexed field, including hashed-index values, may slow inserts. If each insert reaches a different index entry and the index is no longer fully in WiredTiger cache, eviction and replacement rise and MongoDB updates the index on disk. MongoDB says building the index after loading the data sorts the keys and inserts them in order. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/method/db.collection.insertMany.md) ## Comparisons and alternatives - MongoDB says hashed indexes store hashes of indexed values and recommends hashed sharding for monotonically changing shard keys because ranged sharding concentrates new writes on one shard. Combined with MongoDB's random-index-entry warning, this implies a trade-off: hashing can spread writes across shards while local hashed-index inserts still touch dispersed index positions. That local insert effect is an inference from the two manual pages, not a measured per-shard UUID penalty. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-hashed/) - One project benchmark reports MongoDB 8 UUIDv7 insert times of 1.14 seconds versus 1.66 seconds for UUIDv4 on 10,000 customer records, and 1.40 seconds versus 1.73 seconds on 10,000 account records. The run used local Docker with fsync disabled and syncdelay set to zero, so these measurements are workload-specific and do not establish a general production speed ratio. (low confidence) — [source](https://github.com/geckonz/uuid-perf-test) ## Facts and statements - MongoDB documents its indexes as ordered B-trees and says each insert must update applicable indexes, which adds write-side work. (high confidence) — [source](https://www.mongodb.com/docs/manual/indexes/) - MongoDB identifies bulk inserts of random values on indexed fields, including hashed indexes, as a possible insert-performance regression. It attributes the slowdown to random index entries increasing index size and, once inserts need distinct entries, raising WiredTiger cache eviction and replacement so index updates reach disk. (high confidence) — [source](https://www.mongodb.com/docs/manual/faq/indexes.md) - For a bulk load of random-keyed documents, MongoDB documents loading into an unindexed collection or dropping and rebuilding the affected index afterward. The manual says the index build sorts the data in memory and inserts keys into all indexes in order. (high confidence) — [source](https://www.mongodb.com/docs/manual/faq/indexes.md)