MongoDB 9.0 uses less CPU than 8.0 and 8.3 in independent Percona benchmark

Percona ran its own benchmark of MongoDB 9.0 against 8.0 and 8.3, after finding no published details about the methodology MongoDB Inc. used to reach the performance numbers it announced. The gain is real, but modest, and depends on your server's bottleneck.

What's at stake, and for whom

When MongoDB Inc. launched version 9.0, it published performance numbers that impressed, but without detailing the methodology. That was the hook for an earlier post by Ivan Groenewold, a Percona engineer, who ended that piece with a direct piece of advice:

Always run your own benchmarks.

Ivan Groenewold, author on the Percona blog

On November 6, 2026, Groenewold published the result of following his own advice. He compared MongoDB Community 9.0.4 against Percona Server for MongoDB (PSMDB) 8.0.34-15 and 8.3.13-4, three identical replica sets running on Google Cloud, under a controlled workload.

This angle matters to anyone deciding whether it's worth migrating a production MongoDB cluster to version 9.0, or whether the upgrade can wait. The reader's decision criterion here isn't "which version is newer," but rather: is your server's bottleneck today CPU, memory, or disk? The answer changes the size of the expected gain.

One caveat the author himself insists on repeating: this is a quick test, with one workload, one hardware configuration, and three data sizes. It is not an extensive benchmark, and he treats the numbers as an initial indication, not a verdict.

Comparison criteria

Analysis by criterion

The CPU gain is the central finding of the test. Groenewold measured that MongoDB 9.0 consumes fewer CPU cycles per operation across all three data volumes (1 million, 4 million, and 8 million documents in the airline.flights collection). This detail explains why the size of the gain changes with the server's bottleneck: when CPU saturates, the savings show up as higher throughput; when it doesn't, they disappear.

With 1 million documents, the entire workload fits comfortably in the operating system's file cache, so the difference between versions showed up mainly in writes (updateOne, updateMany, deleteOne, deleteMany, batch inserts of 10 documents). Finds, which make up 60% of the workload, essentially tied across all three versions at this volume.

With 4 million documents, the picture flipped: finds started showing the biggest difference, with MongoDB 9.0 up to 12% faster than PSMDB 8.0. This is the point where the WiredTiger cache can no longer hold everything comfortably, and every read that has to go to disk costs CPU to decompress and process, which favors the version that spends fewer cycles per operation. This is the scenario the author himself describes as CPU-bound.

With 8 million documents, the compressed collection (at a compression ratio of roughly 2:1) ended up the same size as the server's total memory, leaving only 25% of the documents actually in the WTcache. In this disk-bound scenario, single-document updates and deletes by flight_id (which need to fetch a document that's likely out of memory) came out equal across versions, or even slightly faster on PSMDB 8.0. MongoDB 9.0 kept its advantage only in finds, inserts, and _id-based operations.

In short: the gain from 9.0 is roughly 6% when CPU is the limiting factor (the 4M-document scenario) and drops to roughly 2% when the bottleneck shifts to memory or disk (the 8M-document scenario). PSMDB 8.3 was consistently the slowest version whenever CPU mattered, a behavior the author himself hasn't explained yet and promises to investigate in a follow-up post.

One point rules out an obvious hypothesis: execution plans. After each run, the load tool (PLGM, Percona Load Generation Machine) ran explain() on samples of each query type. All three versions chose exactly the same plans, at every data size: LIMIT → FETCH → IXSCAN on the flight_id_1_equipment.plane_type_1 index for finds, the same path for updates and deletes by flight_id, and EXPRESS_UPDATE/EXPRESS_DELETE on the _id_ index for bulk identifier-based operations. In other words, the performance difference doesn't come from the optimizer choosing a better or worse path: it comes from how much CPU work each version spends executing the same plan.

The methodology deserves a mention because it's unusual to see this much detail in a database benchmark. Groenewold published the complete environment setup (three-node replica sets on n2-standard-4 instances on Google Cloud, pd-ssd disks, Intel Ice Lake platform), the PLGM parameters (16 workers with no wait time between commands, PLGM_WORKLOAD_DETERMINISTIC=true, fixed seeds), and even the fingerprint hash of the generated traffic, so that anyone can reproduce the test byte for byte. Writes used the server's default write concern, so they include replication in the measured time, which brings the test closer to real production on a replica set.

Verdict by use case

For those running a cluster where CPU is already at its limit (heavy reports, many concurrent connections, read-intensive load competing with writes), MongoDB 9.0 offers a real, measurable gain of roughly 6%. It's worth setting aside a staging environment and repeating a similar test with the application's typical workload before deciding.

For those running a small or medium database where the data fits comfortably in the memory cache, the gain drops to roughly 2%, which hardly justifies the maintenance window and the risk of a major version upgrade in production. In that case, the migration can wait for the next regular update cycle.

For those who already use PSMDB 8.3 specifically for Percona-exclusive features (the test disabled all of them to keep the comparison fair), the result calls for extra caution: 8.3 was the slowest version whenever CPU mattered, and there's still no published explanation for it. Before migrating to 9.0 and dropping 8.3, it's worth running the same test with Percona's features enabled, because they could change the picture.

For teams that already have an independent reason to migrate, such as end of support for an older version, the result is reassuring: there's no sign of latency or throughput regression between 8.0, 8.3, and 9.0 under the tested load pattern. The migration can proceed on its normal schedule, with a small gain expected as a bonus, not as a reason to speed up the plan.

The author himself sums up the tone that should guide any decision:

Treat 9.0 as a release to test, not one you have to deploy urgently.

Ivan Groenewold, author on the Percona blog

What still can't be said

The test covered a single workload, the "flights" workload built into PLGM (the airline.flights collection with 7 secondary indexes, a mix of 60% finds, 20% updates, 10% deletes, and 10% inserts). Workloads with heavy aggregations, multi-document transactions, or very different access patterns (the test ran with PLGM_AGGREGATE_PERCENT=0 and PLGM_TRANSACTION_PERCENT=0) weren't measured and might behave differently.

Also still missing: varying concurrency and disk type. The author used a fixed 16 workers and Google Cloud's standard SSD, and already announces that the next step is to test other concurrency levels and faster disks, as well as investigate why PSMDB 8.3 consumes more CPU than the other two versions.

As of this publication, there is no third-party replication of this test, nor a direct comparison with the original numbers published by MongoDB Inc. (which prompted Groenewold's earlier post, precisely for lack of published methodology details). Until that happens, Percona's result is the most transparent reference available, but it remains, in the author's own words, "a quick first test, not an extensive benchmark by any measure."

The material provided by the source didn't include any image or video URL that met this outlet's media criteria, so the text proceeds without an embedded visual element.

Source

1. Percona Database Blog: "MongoDB 9.0 vs. 8.0 vs. 8.3: A Quick First Look at Performance," by Ivan Groenewold, published November 6, 2026 (https://www.percona.com/blog/mongodb-9-0-vs-8-0-vs-8-3-a-quick-first-look-at-performance/).