Improving MongoDB Million-Collection Performance with Shared WiredTiger Table Space

MongoDB on Tencent Cloud is widely used in gaming, e‑commerce, UGC, and IoT. As customers create massive numbers of databases and collections—sometimes reaching the million‑level—performance degrades sharply, leading to slow queries, frequent OOM, and instance start‑up times of hours.

The MongoDB team at Tencent Database R&D Center performed a detailed performance analysis on the native v4.0 engine. All observed bottlenecks originated from the WiredTiger (WT) storage engine, especially the explosion of data handles, cache pressure, and schema‑lock contention when the number of collections grows.

Key findings :

Each collection and index creates an independent WT table, causing the number of WT tables to grow linearly with user‑created collections.

Data handles (dhandles) remain active for long periods; the sweep thread cleans them too slowly (default close_idle_time ≈ 28 h), leading to high memory usage and lock contention.

WT’s hash bucket for data‑handle cache is 512 buckets; with millions of tables the bucket lists become very long, dramatically slowing look‑ups.

Startup involves serial reconfiguration of each WT table, making instance start‑up time proportional to the number of collections.

To address these issues, the team designed a shared table‑space architecture based on a prefix‑mapping strategy:

All user collections share a single logical WT table space; the KVEngine layer adds a unique prefix to each key before handing it to WT.

Metadata about the prefix‑to‑collection mapping is stored in a special _mdb_catalog.wt file.

Only nine physical WT tables are ever created (e.g., WiredTiger.wt , WiredTigerLAS.wt , _mdb_catalog.wt , sizeStorer.wt , oplog-collection.wt , etc.), regardless of how many logical collections exist.

This redesign eliminates the data‑handle explosion, reduces schema‑lock contention, and makes startup almost constant time. The team validated the design with a 2‑core/4 GB replica set, creating up to 500 GB of data (≈200 M records) across 500 k–1 M collections. Results:

Read/write throughput increased by 1–2 orders of magnitude.

Memory consumption dropped dramatically; OOM no longer occurs even with 1 M collections.

Instance start‑up time shrank from hours to under one minute.

QPS after optimization is comparable to a single‑table native deployment, while the pre‑optimization QPS dropped by >90 %.

Limitations of the shared‑space approach include: space is not reclaimed immediately after collection deletion (it can be reused), some operations such as compact and validate are not yet supported, and storage‑size statistics become logical rather than physical.

Overall, the shared table‑space solution provides a scalable path for MongoDB deployments that need to manage millions of collections, delivering significant performance, memory, and startup‑time improvements while keeping full MongoDB compatibility.