MongoDB 9.0, Atlas Infinite and Atlas Agent Engine: What to Evaluate

On 29 September 2026, MongoDB announced three things at once: general availability of MongoDB 9.0, a public preview of a new Atlas deployment option called Atlas Infinite, and a public preview of Atlas Agent Engine for AI agents. The existing Atlas offering is being renamed Atlas Core.

These announcements sit at different maturity levels and apply to different routes. This article separates what is generally available from what is in preview, explains the engineering trade-offs of each, and sets out what to evaluate before changing plans. It covers the partner-led routes, MongoDB Atlas and MongoDB Enterprise Advanced. Self-managed MongoDB Community Server is a separate route.

What was announced, and how mature each part is

The MongoDB 9.0 and Atlas Infinite press release and the linked product updates give the status of each item:

Item	Status on the research date	Where it applies
MongoDB 9.0	Generally available	Atlas, Enterprise Advanced and Community Edition
Queryable Encryption prefix, suffix and substring queries	Generally available	Atlas, Enterprise Advanced and Community Edition
Intelligent Workload Management	Generally available	Eligible Atlas 9.0 clusters
Atlas Infinite	Public preview, AWS only	Atlas
Atlas Agent Engine	Public preview	Atlas customers; wider deployment described as planned or possible

A public preview is for evaluation. Features, limits and documentation can change, and preview services may carry different commercial and support terms. Treat the two previews as items to test, not as foundations for a production plan yet.

MongoDB 9.0: what changes in the database

The MongoDB 9.0 release page lists the new capabilities: scaling-efficiency work, Intelligent Workload Management, new Queryable Encryption query types, schema constraints for database-enforced data rules, and enhanced Atlas private networking. MongoDB publishes performance comparisons against 8.0. We do not repeat vendor figures; measure your own workload before and after.

Three items deserve attention from architects.

• Queryable Encryption. The Queryable Encryption update adds prefix, suffix and substring queries on encrypted fields, joining existing equality and range queries. Substring queries have documented limits on field and search-term length. Check those limits against your data, and plan key management before adopting it.
• Intelligent Workload Management. The Intelligent Workload Management update describes an Atlas 9.0 capability that queues transient traffic spikes and keeps clusters responsive under overload. Optional Load Shedding rejects excess work during sustained overload. It is on by default for eligible Atlas 9.0 clusters, so test how your clients handle queued or rejected operations and retries.
• Schema constraints. Database-enforced data rules can move validation from application code into the database. That improves consistency but can turn previously accepted writes into errors, so introduce constraints gradually.

Upgrading to 9.0

The route determines the procedure. For Atlas, MongoDB directs users to the Atlas major-version change tutorial. For self-managed Enterprise Advanced, the MongoDB 9.0 upgrade notes describe upgrading from 8.3, with featureCompatibilityVersion set to 8.3 first, and link a separate procedure for upgrading from 8.0. They also require all cluster members to be running before an upgrade starts.

The release page states that from MongoDB 8.0, major versions follow a standard five-year lifecycle. Confirm your own dates on MongoDB’s lifecycle schedule. A sensible sequence is:

1. Inventory clusters, current versions and feature compatibility versions.
2. Read the 9.0 compatibility changes and confirm driver and operating system support.
3. Upgrade a staging environment that mirrors production topology.
4. Replay representative workload and compare query plans and error rates.
5. Test rollback or downgrade steps before the production change.
6. Raise the feature compatibility version only after the new version is proven.

Atlas Infinite: a new architecture, with preview limits

The Atlas Infinite documentation describes a database edition that separates compute from storage. Queries run on compute nodes; MongoDB manages storage independently. Scaling the cluster tier, adding read-only nodes or recovering from node failure happens without moving or copying data. Applications use the same wire protocol and query API, so MongoDB states no code changes are needed.

The preview comes with substantial limits. The documentation lists, among others:

• AWS only, with all nodes in a single region; no multi-region, multi-cloud or global clusters.
• No sharded clusters, and no cluster tiers from M80 upwards.
• No Atlas Search or Vector Search on Infinite clusters.
• No uptime SLA during public preview.
• No database profiler, Online Archive or Atlas Kubernetes Operator support.
• No change of edition after creation, in either direction, and no live migration or backup-restore between Atlas Core and Atlas Infinite.

The last point shapes any trial. Moving data means creating a new Infinite cluster and loading it, for example with mongodump and mongorestore. Billing also differs: the documentation links a separate Atlas Infinite costs page, so model cost with your own usage pattern. For workloads with sudden demand changes, Infinite is worth a structured test. For multi-region resilience or search-heavy applications, Atlas Core remains the documented route during the preview.

A useful trial is narrow and measurable. We would structure it like this:

1. Choose one workload with variable demand and no dependency on unsupported features.
2. Define success criteria in advance: scaling behaviour, error rates under load, operational effort and cost.
3. Create a new Infinite cluster in a supported AWS region and load a representative dataset.
4. Replay recorded or synthetic traffic, including demand spikes, against both Atlas Core and Infinite.
5. Exercise backup, point-in-time restore and node-failure recovery on the Infinite cluster.
6. Record the results, the open limitations and the cost model, then decide whether to wait for general availability.

Keep the trial isolated from production data flows until the preview terms, including data handling, are accepted by your security and legal teams.

Atlas Agent Engine: an execution and memory layer for agents

The Atlas Agent Engine press release describes a unified execution, memory and governance layer for production AI agents. Its components include Atlas Agent Runtime and Atlas Agent Memory, which customers can adopt together or separately. MongoDB states that memory uses Voyage AI embeddings and native retrieval, that actions are logged against human or agent identities under policy, and that the engine builds on the MCP and A2A open standards.

The press release also says the engine will run across clouds, self-managed environments or a laptop, but the deployment options available today should be confirmed. Before building on it, answer these questions:

• Which data do agents read and write, and where does agent memory live?
• How do identity, audit records and policy integrate with your existing access controls?
• What are the preview’s terms for support, data handling and pricing?
• How would you leave? The open-standard interfaces help, but memory, logs and policies also need a migration path.

Agent platforms are a fast-moving field. Evaluate against an internal reference design, such as the one in our enterprise AI AgentOps solution, so that platform choice follows requirements.

Choosing a route after the announcements

Route	What you operate	Consider when
Atlas Core	Application and data model; MongoDB operates the service	You need a managed service now, including multi-region, sharding or Atlas Search
Atlas Infinite (preview)	As Atlas, on a decoupled architecture	You want to test elastic scaling on AWS and accept preview limits
Enterprise Advanced	Your infrastructure, with MongoDB’s commercial licence, tooling and support	Data must stay in your environment and you want vendor support
Community Server	Everything; source-available under the SSPL, self-supported	You accept full operational responsibility and the SSPL terms

Capabilities, support and pricing differ by edition and contract, so confirm each one against your subscription. The Community route is described on our MongoDB Community Server page.

Evaluation checklist

• Every cluster’s route, version and feature compatibility version is recorded.
• A 9.0 upgrade plan exists per route, with a staging rehearsal and rollback steps.
• Client retry behaviour is tested against Intelligent Workload Management on Atlas 9.0.
• Queryable Encryption use cases are checked against documented query limits and key management.
• Any Atlas Infinite trial uses a new cluster, a defined data-load method and its own cost model.
• Preview limits, including no uptime SLA, are accepted in writing for any preview workload.
• Atlas Agent Engine is assessed for data handling, identity, audit and exit path before adoption.
• Edition and contract entitlements are confirmed with MongoDB for each feature you plan to use.

How Bassirah can help

MongoDB is a Bassirah strategic technology partner. We help teams plan and rehearse 9.0 upgrades, design structured trials of Atlas Infinite and Atlas Agent Engine, and compare routes against their requirements. See our MongoDB partner page; edition, licensing and support entitlements are confirmed in each engagement.