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.
MongoDB’s benchmarks, comparing 9.0 with 8.0, report up to:
Those 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.
One of the more interesting changes is a new per-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.
We’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.
Now 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.
MongoDB also introduces a limit on concurrently open multi-document transactions, defaulting to 10,000. Again, this is mostly about preventing one workload from consuming unlimited resources. Not particularly exciting.
Another change more useful than flashy is the expansion of $queryStats. In 9.0, query statistics cover inserts, updates, and deletes in addition to reads.
This 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.
If you already have tooling consuming $queryStats, however, check it before upgrading. The structure and serialization of the output have changed in 9.0.
MongoDB 9.0 also expands querySettings and introduces per-query knobs.
The 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.
In 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.
MongoDB 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.
There is a catch, though. The 9.0 implementation is not compatible 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.
MongoDB 9.0 changes behavior around things such as:
None of these is going to make a great product announcement. But these are exactly the things you should test before upgrading a production cluster.
For 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 against real production-like data.
Percona has already started working on Percona Server for MongoDB 9.0, and we expect to have more to share about it soon.
That’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. 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.
To 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.
I 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.
Resources
RELATED POSTS
