{"slug": "mongodb-9-0-more-8-4-than-9-0", "title": "MongoDB 9.0: More 8.4 than 9.0?", "summary": "MongoDB 9.0 ships with a new per-operation memory limit defaulting to 1 GB or 20% of available server memory (whichever is greater), a 10,000 default cap on concurrently open multi-document transactions, and expanded $queryStats covering inserts, updates and deletes, but the release lacks a feature that fundamentally changes how MongoDB is run, according to the review. The review notes MongoDB's benchmarks claim up to 35% gains versus 8.0 without published methodology or raw data, and warns that queries which worked on 8.x can now fail on 9.0 and that $queryStats output structure and serialization changed, so existing tooling must be checked before upgrading. The review also flags that prefix, suffix and substring queries on encrypted strings are generally available but are not compatible with the Queryable Encryption Public Preview from MongoDB 8.2 and 8.3, and that Automatic Encryption is not part of Community Edition.", "body_md": "MongoDB 9.0 is here. Strip away the marketing around AI, Atlas, and “the best version ever built”, and MongoDB 9.0 starts to look a lot like MongoDB 8.4. Sure, there are some useful changes, but I don’t see a single feature that fundamentally changes how we run MongoDB.\n\nMongoDB’s benchmarks, comparing 9.0 with 8.0, report up to:\n\nThose are significant numbers, but at the time of this writing I could not find any details about the methodology used or the raw data of the tests performed. Don’t expect your production workload will suddenly become 35% faster. Your mileage will depend on indexes, document sizes, working set, storage, and a dozen other things. Always [run your own benchmarks](https://www.percona.com/blog/introducing-percona-load-generator-for-mongodb-clusters-the-benchmark-tool-that-simulates-your-actual-application/). \n\nOne of the more interesting changes is a new [per-operation memory limit](https://www.mongodb.com/docs/manual/core/aggregation-pipeline-limits/#std-label-operation-memory-limit). By default, an operation can use up to 1 GB or 20% of available server memory, whichever is greater. If it goes beyond that, the operation can fail.\n\nWe’ve all seen queries that had a rather unfortunate effect on the server. One aggregation starts consuming memory, other workloads get squeezed, and suddenly the database has a problem.\n\nNow MongoDB has another mechanism to stop this from getting out of control. The downside is that a query that “worked” on 8.x can now fail on 9.0.\n\nMongoDB also introduces a [limit on concurrently open multi-document transactions](https://www.mongodb.com/docs/manual/reference/parameters/#mongodb-parameter-param.maxConcurrentMultiDocumentTransactions), defaulting to 10,000. Again, this is mostly about preventing one workload from consuming unlimited resources. Not particularly exciting.\n\nAnother change more useful than flashy is the expansion of [$queryStats](https://www.mongodb.com/docs/manual/reference/operator/aggregation/querystats/). In 9.0, query statistics cover inserts, updates, and deletes in addition to reads.\n\nThis is important because when troubleshooting a busy MongoDB server, looking only at queries isn’t enough. A workload can be spending most of its time doing writes. Having the same query-shape visibility across reads and writes makes it easier to determine what MongoDB is spending its time doing.\n\nIf you already have tooling consuming $queryStats, however, check it before upgrading. The structure and serialization of the output have changed in 9.0.\n\nMongoDB 9.0 also expands [querySettings](https://www.mongodb.com/docs/manual/reference/command/setquerysettings/#mongodb-dbcommand-dbcmd.setQuerySettings) and introduces per-query knobs.\n\nThe interesting part here is that we can increasingly tune a particular query instead of changing the global setting for that particular query shape, just because one query is misbehaving.\n\nIn a shared environment, global tuning is often a compromise. You fix one workload and potentially make another one worse. Being able to say “this query gets this setting” can be useful.\n\nMongoDB 9.0 makes prefix, suffix, and substring queries on encrypted strings generally available. This is a real improvement if you have an application that needs searchable encrypted data.\n\nThere is a catch, though. The 9.0 implementation is [not compatible](https://www.mongodb.com/docs/manual/release-notes/9.0-compatibility/#queryable-encryption-prefix-suffix-and-substring-public-preview-to-ga-migration) with the Queryable Encryption Public Preview implementation from MongoDB 8.2 and 8.3. Also, MongoDB decided to not make Automatic Encryption part of Community Edition, which makes it harder to adopt the feature.  \n\nMongoDB 9.0 [changes behavior](https://www.mongodb.com/docs/manual/release-notes/9.0-compatibility/#compatibility-changes-in-mongodb-90) around things such as:\n\nNone of these is going to make a great product announcement. But these are exactly the things you should test before upgrading a production cluster.\n\nFor example, if you have custom change-stream consumers, test what happens during an election. If you have application code relying on server-side JavaScript, check its date handling. If you have heterogeneous documents, [test your null queries](https://jira.mongodb.org/browse/SERVER-36681) against real production-like data.\n\nPercona has already started working on Percona Server for MongoDB 9.0, and we expect to have more to share about it soon.\n\nThat’s worth mentioning because PSMDB isn’t simply about following upstream MongoDB releases. Percona also continues to make [enterprise-grade capabilities available without an Enterprise Edition license](https://docs.percona.com/percona-server-for-mongodb/8.3/comparison.html). Features such as LDAP authentication, audit logging, hot backup, and encryption at rest are available in PSMDB without the additional licensing costs associated with MongoDB Enterprise.\n\nTo sum up, MongoDB 9.0 is useful, but I don’t see the kind of changes that makes me rush to upgrade. In fact, several of the changes are good engineering decisions. More performance, limits around runaway workloads, improving query visibility, and more targeted query tuning all make sense. But calling this a major leap feels like a stretch.\n\nI would treat MongoDB 9.0 as a release to test and understand, rather than a release you urgently need to deploy. Maybe “MongoDB 8.4” would have been a more fitting name.\n\nResources\n\nRELATED POSTS", "url": "https://wpnews.pro/news/mongodb-9-0-more-8-4-than-9-0", "canonical_source": "https://www.percona.com/blog/mongodb-9-0-more-8-4-than-9-0/", "published_at": "2026-10-09 17:04:39+00:00", "updated_at": "2026-10-23 17:42:27.433317+00:00", "lang": "en", "topics": ["artificial-intelligence"], "entities": ["MongoDB", "MongoDB 9.0", "MongoDB 8.4", "MongoDB 8.0", "MongoDB 8.2", "MongoDB 8.3", "Percona", "Atlas"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/mongodb-9-0-more-8-4-than-9-0", "markdown": "https://wpnews.pro/news/mongodb-9-0-more-8-4-than-9-0.md", "text": "https://wpnews.pro/news/mongodb-9-0-more-8-4-than-9-0.txt", "jsonld": "https://wpnews.pro/news/mongodb-9-0-more-8-4-than-9-0.jsonld"}}