MongoDB storage tiering test lifts throughput up to 5.2x
MongoDB storage tiering increased throughput by between 1.6x and 5.2x in a proof of concept published by Percona on November 2, 2026. The results suggest that workloads focused mainly on recent records may have an alternative to immediately buying larger machines or introducing sharding, although the software has not run in production and produced significantly worse update-tail latency in testing.
The underlying problem begins when a MongoDB replica set, a group of database servers that maintain copies of the same data, grows beyond available memory. Its working set, meaning the data used frequently enough to benefit from fast access, no longer fits inside the WiredTiger cache, the area of memory MongoDB uses to serve data efficiently. Uncached documents must then be read from storage. In the tested cluster, a read p95 of 70 milliseconds, meaning 95 percent of reads completed within that time, reflected a disk operating at its input/output operations per second (IOPS) limit rather than an inefficient index.
Sharding can divide a large database across multiple machines, but it introduces a shard key that determines where records live, mongos routing processes, configuration servers and balancing. Queries generally need the shard key to remain efficient, while changing that key is not straightforward. The proof of concept, called Thermocline, instead places a smaller replica set holding recent records in front of the original cluster. The existing replica set remains intact as the archive, and the application connects to a proxy using MongoDB's normal communications protocol rather than directly to the old cluster.
Four components manage the arrangement. The proxy sends a query to the fast tier only when that tier can establish that it contains the complete answer; otherwise, the query goes to the archive. New writes initially enter the fast tier. A feeder reads its change stream, MongoDB's running record of database changes, and reproduces every write in the archive so that the archive retains all documents. An evictor deletes records from the fast tier after they exceed the configured age for their collection, but only after confirming that the archive has them. A warmer copies records newer than that age from the archive into the fast tier. The fast tier can therefore begin empty and fill through both incoming traffic and background warming, without manual loading.
Percona reported that the test ran on Hetzner Cloud. The existing deployment was a three-member replica set containing 40 million simulated orders and 47 GB of data. Each member was limited to 2.5 GB of memory, including a 1 GB WiredTiger cache, and its data disk was capped at 3,000 reads per second. The dataset was therefore about 47 times larger than the cache. The second tier was another three-member replica set and started empty.
The workload used Yahoo! Cloud Serving Benchmark (YCSB) 0.17, a tool for generating repeatable database traffic, with 64 threads. Runs lasted ten minutes, with two runs on each side of the comparison. Every simulated document had a date distributed across the preceding year. The online-store mix comprised 85 percent reads, 10 percent updates and 5 percent inserts, with reads favouring the newest documents. A read-heavy mix used 95 percent reads and 5 percent updates with the same recency pattern. A concentrated variation used that 95-to-5 mix but directed 99 percent of all activity to the newest 9 percent of documents. Each workload ran against the original cluster alone and against the same cluster behind Thermocline, using the same MongoDB release, resource limits and client.
Across those runs, the capped cluster completed 1.6x to 5.2x more operations per second behind the tiering proxy, with no refused operations. The largest improvement came from the concentrated workload, which rose from 4,447 to 23,340 operations per second. Its read p95 dropped from 86 to 6 milliseconds, while p99, the point within which 99 percent of reads completed, fell from 92 to 8 milliseconds.
A fixed-load comparison used a requested 6,165 operations per second for the store workload, matching the original cluster's maximum. On its own, that cluster delivered 6,086 operations per second with a 70.5 millisecond read p95. Behind Thermocline, two runs delivered 6,156 and 6,159 operations per second, with p95 results of 2.8 and 2.1 milliseconds. Read p99 varied between 7 and 27 milliseconds across the tiered runs, compared with 81 milliseconds for the archive alone. Disk reads on the archive declined from 2,704 to 1,838 per second.
The empty-start test measured the more realistic adoption path. During 30 minutes of the store workload running without an imposed throughput limit, the pair averaged 8,221 operations per second. That was 42 percent above the original cluster's 5,803 operations per second with cold caches. The tiered setup passed the old cluster's result after 100 seconds, averaged 6,417 operations per second during the first five minutes and 9,146 during the final five. During that period, it copied 271,271 documents from the archive into the fast tier.
The limitations are substantial. Every write must still reach the archive, and mirroring an update requires the archive to read the existing document from disk first. Updates in the store workload remained constrained by the old cluster, while update p99 deteriorated to between 455 and 472 milliseconds, compared with 104 to 189 milliseconds without Thermocline. That tail-latency issue remains unresolved in the proof of concept. Queries covering records outside the fast tier are also sent to the archive and remain as slow as before, so workloads reading evenly across their full history should expect little benefit.
Both tiers must use the same MongoDB release because the archive directly executes application queries and must understand them. An older deployment would consequently need upgrading before adoption. Most importantly, Thermocline has an extensive test suite but has not carried production traffic. Its measured gains belong to this test cluster and workload, not to every MongoDB installation, so organisations would need to reproduce their own traffic patterns and failure tests before drawing conclusions. The code and operating instructions are available in the Thermocline repository under the Apache 2.0 licence.
For organisations evaluating where to run database tiers, AEU Data provides European cloud and data infrastructure as one available infrastructure option. The broader lesson is that MongoDB storage tiering may relieve a memory-constrained replica set when recent data dominates reads, but it does not remove archive write costs, accelerate historical queries or replace production validation.