As an application grows, its database requirements do not always increase at the same rate.
A business application might accumulate terabytes of customer records, transaction history, and application logs while its query workload remains relatively stable. Another application might have a moderate amount of data but experience sudden increases in traffic during product launches or seasonal events.
In traditional database architectures, storage and compute resources are often provisioned together. Increasing database capacity can therefore involve changing the cluster tier even when the application needs more storage rather than additional processing power.
MongoDB Atlas Infinite addresses this challenge by separating compute and storage into independent layers.
The compute layer runs database queries, transactions, and aggregations. The storage layer maintains the database data independently of the compute nodes. This architecture allows teams to scale compute without moving data and grow storage without increasing the cluster tier.
However, Atlas Infinite also introduces different operational and billing considerations compared with traditional Atlas clusters.
This article explains how the architecture works, how independent scaling affects application design, what developers should check before migrating, and how to evaluate whether Atlas Infinite fits a growing MongoDB workload.
Understanding the Difference Between Atlas Core and Atlas Infinite
MongoDB Atlas provides two database editions: Atlas Core and Atlas Infinite.
Atlas Core uses an architecture in which compute and storage are associated with individual database nodes. Each data-bearing node runs MongoDB and maintains its own database storage.
Atlas Infinite separates these responsibilities.
The compute nodes execute database operations, while a separately managed storage layer maintains the data and handles durability and replication.
The difference affects how teams scale their databases.
Area | Atlas Core | Atlas Infinite |
|---|
Architecture | Compute and storage are coupled on each node | Compute and storage are independent layers |
Storage scaling | Depends on the cluster's storage configuration and tier limits | Storage expands independently as data grows |
Compute scaling | Changing the cluster tier changes node resources | Compute tier can change without moving stored data |
Data recovery | Replacement nodes may need to synchronize data | New compute nodes connect to the existing storage layer |
Storage management | Storage configuration is associated with nodes | MongoDB manages a shared storage layer |
Billing | Depends on the selected Atlas configuration | Compute, storage, backup, and data transfer are separate dimensions |
The main architectural benefit is independent scaling.
For example, if an application needs more query-processing capacity but its data size has not changed significantly, the team can increase compute resources without resizing its storage.
Similarly, if the application accumulates more records but does not require additional processing capacity, storage can grow without automatically requiring a larger compute tier.
How the Atlas Infinite Architecture Works
Atlas Infinite separates the database into two primary layers.
Compute Layer
The compute layer runs the MongoDB database processes responsible for:
Executing queries.
Processing aggregation pipelines.
Handling transactions.
Managing indexes.
Processing application reads and writes.
Serving database connections.
A cluster has two electable compute nodes: a primary and a standby.
The primary handles writes, while the standby can take over if the primary fails or restarts.
Atlas Infinite also supports additional read-only and analytics nodes for workload isolation.
During public preview, a cluster can have up to five additional nodes, giving it a maximum of seven nodes in total.
The additional nodes can serve read workloads but cannot become the primary.
Storage Layer
The storage layer maintains the application's database data independently of the compute nodes.
It is responsible for:
Persisting database changes.
Maintaining multiple copies of data for high availability.
Supporting reads from compute nodes.
Managing replication at the storage layer.
Supporting backup and recovery operations.
Because the storage layer is independent, replacing or scaling compute nodes does not require copying the complete database to the replacement nodes.
This changes how database recovery and scaling work.
For example, when a compute node fails, the standby can take over without requiring a traditional initial data synchronization from another database node.
Scaling Compute Independently
Compute capacity determines how much processing power is available for database operations.
An application may need additional compute resources when:
Query volume increases.
More users access the application simultaneously.
Aggregation workloads become more demanding.
Transaction volume increases.
Reporting operations compete with normal application traffic.
With Atlas Infinite, teams can change the cluster tier without changing the amount of data the cluster can store.
For example, consider an application that initially uses an M20 cluster tier.
As traffic increases, query execution becomes slower. The database team investigates the workload and determines that additional CPU and memory resources are required.
The team can move to a higher supported tier without resizing the storage layer.
The following table illustrates the concept:
Situation | Required change |
|---|
More database traffic | Increase compute capacity |
More concurrent queries | Evaluate compute capacity and workload isolation |
Larger application dataset | Allow storage to grow |
Reporting affects operational queries | Add analytics nodes where supported |
More read capacity required | Add read-only nodes where supported |
Compute node failure | Use the standby and managed storage architecture |
A higher cluster tier also provides more storage throughput and IOPS. Therefore, compute scaling can improve the storage performance available to the workload.
However, changing the compute tier should not replace query optimization.
An inefficient query can remain inefficient even after additional resources are allocated.
Scaling Storage Independently
One of the main differences between Atlas Infinite and traditional Atlas Core clusters is storage management.
With Atlas Infinite, MongoDB manages storage independently of compute nodes.
Developers do not need to provision a separate disk for each node or enable traditional disk auto-scaling.
Storage expands as the database grows, subject to the configured maximum storage limit.
During public preview, Atlas Infinite supports up to 128 TB of logical data per replica set.
Logical data size represents the uncompressed size of database collections and indexes. It is not necessarily the same as the physical storage capacity used internally by the service.
Configure a Maximum Storage Limit
Although storage grows automatically, teams can define a maximum logical storage limit.
This helps establish a boundary for database growth.
For example, suppose an application has a planned storage capacity of 5 TB.
The database administrator can configure a maximum storage limit of 5 TB rather than allowing the cluster to use its full available capacity.
When the logical data size approaches the configured limit, Atlas provides an alert by default when usage exceeds 90%.
If the cluster reaches its maximum storage limit, Atlas blocks writes while continuing to serve reads.
This behavior is important for application design.
An application that reaches its storage limit may still allow users to retrieve existing information, but operations that insert or update data can fail.
Do not treat the maximum storage limit as a normal capacity-management mechanism. Monitor storage growth and investigate the cause before the cluster approaches the limit.
During public preview, Atlas may throttle writes before the configured limit is reached to preserve system availability.
Understanding Read-Only and Analytics Nodes
Separating compute from storage also changes how additional database nodes can be used.
Atlas Infinite supports additional read-only and analytics nodes that access the shared storage layer.
These nodes can help isolate different workloads.
Read-Only Nodes
Read-only nodes provide additional capacity for application reads.
Consider an application that handles thousands of product searches while also processing customer orders.
The primary node handles writes and can also serve reads. The standby provides another location for eligible read operations.
If the application needs additional read capacity, it can add read-only nodes and distribute suitable queries across them.
MongoDB drivers support read preferences that determine which replica set members can serve reads.
For example, an application can use secondaryPreferred:
const { MongoClient } = require("mongodb");
const client = new MongoClient(
process.env.MONGODB_URI,
{
readPreference: "secondaryPreferred"
}
);
This preference allows reads to use secondary nodes when available, with the primary as a fallback.
The application should still consider consistency requirements.
A read immediately following a write may need to go to the primary to ensure that the application observes the latest data.
Analytics Nodes
Analytics nodes help isolate analytical queries from operational database traffic.
Consider a retail application that performs two different types of work:
Large aggregation pipelines can consume resources that would otherwise be available for normal application requests.
Analytics nodes provide separate compute resources for suitable reporting workloads.
The application can direct analytical queries to those nodes using MongoDB read preferences and predefined replica set tags.
For example, a connection string can use a tag-based read preference:
mongodb+srv://username:[email protected]/store
?readPreference=secondary
&readPreferenceTags=nodeType:ANALYTICS
The tag must match the configuration exposed by the Atlas deployment.
Do not route every read operation to analytics nodes. Operational queries may have different consistency and latency requirements.
Understand How Writes and Replication Work
Atlas Infinite handles replication differently from Atlas Core.
In Atlas Core, replica set members maintain their own data copies and use the replication mechanism associated with the oplog.
In Atlas Infinite, replication is handled by the storage layer.
The compute nodes access the shared storage layer rather than maintaining independent data copies in the traditional way.
This difference also affects write concern.
Atlas Infinite uses w: "majority" as its default write concern.
The meaning of majority is different from a traditional replica set majority. It refers to the storage layer's replication and acknowledgment behavior rather than a majority of compute nodes.
For example:
db.orders.insertOne(
{
customerId: 1001,
amount: 2500,
status: "confirmed"
},
{
writeConcern: {
w: "majority",
wtimeout: 5000
}
}
);
The wtimeout option sets a time limit for the write acknowledgment.
If Atlas cannot acknowledge the write within that period, the application receives a write concern error.
Without a configured timeout, a write waiting for acknowledgment can continue waiting indefinitely.
Review write concern settings during migration, especially if the application has explicit write concern configurations.
Also remember that Atlas Infinite always applies journal acknowledgment internally. The application's j setting does not disable this behavior.
How Atlas Infinite Changes Database Recovery
Traditional database scaling and recovery can require moving or synchronizing data between database nodes.
This process may take time when the dataset is large.
Atlas Infinite keeps data in its independent storage layer.
When compute capacity changes or a node fails, the replacement or newly configured compute node connects to the existing storage layer.
This reduces the need for a traditional initial data synchronization.
Backup, restore, and point-in-time recovery operations also operate at the storage layer.
This architecture can simplify some recovery operations because backup and recovery activity does not depend on the same compute resources that execute application queries.
However, the architecture does not eliminate the need for disaster recovery planning.
Teams should still define:
Recovery Point Objective (RPO).
Recovery Time Objective (RTO).
Backup retention requirements.
Regional recovery requirements.
Data restoration procedures.
Application failover behavior.
Zone resilience and regional disaster recovery are different capabilities. Verify the available recovery options against the application's requirements.
Understand Atlas Infinite Billing
Independent scaling also changes how costs are calculated.
Atlas Infinite meters the following dimensions separately:
Compute.
Storage.
Backup.
Data transfer.
Compute Costs
Compute is billed based on the configured cluster tier and additional nodes.
The primary and standby form a highly available shard, which is the compute billing unit used by Atlas Infinite.
Additional read-only or analytics nodes are billed separately.
An important consideration is that provisioned compute is billed even when the cluster is idle.
Therefore, scaling compute down during periods of low demand can help manage costs when the workload allows it.
Storage Costs
Storage is billed independently based on the volume of uncompressed logical data stored.
The amount of data held in collections, indexes, and the oplog contributes to storage usage.
Increasing the compute tier does not automatically increase storage capacity, and growing the stored dataset does not automatically require a larger compute tier.
Backup Costs
Backup is a separate billing dimension.
Atlas Infinite includes a 24-hour continuous cloud backup window at no additional cost. Additional retained backup history can generate separate charges.
Review backup retention requirements rather than assuming that storage and backup are included in one price.
Data Transfer Costs
Data transfer is also billed separately according to Atlas data transfer pricing.
Internal replication within the Atlas Infinite storage layer is not charged as customer data transfer.
Before deployment, estimate the cost of all four dimensions. A compute-only estimate will not represent the total database bill.
Current Public Preview Limitations
Atlas Infinite has important availability restrictions during public preview.
As of the current documentation, the supported configurations include:
Area | Public preview support |
|---|
MongoDB version | Latest MongoDB 9.x release |
General cluster tiers | M10 through M60 |
Low-CPU cluster tiers | M40 through M60 |
Storage capacity | Up to 128 TB logical data per replica set |
Active collections and indexes | Up to 5,000 combined |
Cloud provider | AWS |
Additional read-only and analytics nodes | Up to five |
Total compute nodes | Up to seven |
Search nodes are not supported during public preview.
Atlas Infinite also does not provide the complete feature coverage available in Atlas Core.
For example, some deployment options and regional configurations may be unavailable.
Before selecting the service, review the current preview availability documentation and confirm that the required features are supported in the intended region.
Public preview capabilities can change, so production decisions should be based on the current service documentation and support commitments.
Common Mistakes When Adopting Atlas Infinite
Mistake | Why it causes problems | Better approach |
|---|
Assuming storage and compute have one combined scaling limit | Teams may increase compute unnecessarily when only storage needs to grow | Evaluate each resource independently |
Ignoring storage billing | Storage costs continue to grow as data accumulates | Monitor logical data size and storage charges |
Treating the storage limit as a normal target | Writes can be blocked when the limit is reached | Set alerts and maintain sufficient headroom |
Sending every read to the primary | The primary can become a bottleneck | Use suitable read-only or analytics nodes |
Ignoring read consistency | Secondary reads may not immediately reflect recent writes | Route consistency-sensitive operations appropriately |
Assuming traditional write concern behavior | Atlas Infinite handles write acknowledgment differently | Review write concern settings |
Ignoring idle compute charges | Provisioned nodes can generate charges without active traffic | Review compute sizing and scaling policies |
Assuming full Atlas Core feature parity | Some capabilities are unavailable during preview | Validate feature compatibility before migration |
Advantages and Disadvantages of Atlas Infinite
Advantages
Compute and storage can scale independently.
Storage grows without requiring traditional disk provisioning.
Compute tier changes do not require moving stored data.
Read-only and analytics nodes provide workload isolation.
The architecture simplifies some node replacement and recovery operations.
Backup and recovery operate independently of the compute layer.
Separate billing dimensions provide visibility into resource consumption.
Disadvantages
Atlas Infinite is currently in public preview.
Supported cluster tiers and cloud regions are limited.
Compute resources are billed even when the cluster is idle.
Storage, backup, and data transfer create separate charges.
Some Atlas Core features are not available.
The maximum storage limit can block writes when reached.
Applications must understand the different write concern and read-routing behavior.
Summary
MongoDB Atlas Infinite separates database compute and storage into independent layers.
This allows teams to increase processing capacity without moving database data and expand storage without automatically increasing the cluster tier.
The architecture also provides additional options for workload isolation through read-only and analytics nodes. Its managed storage layer handles replication, durability, and recovery independently of the compute nodes.
However, adopting Atlas Infinite requires more than understanding its scaling model. Developers and database administrators must review read preferences, write concern, storage limits, backup costs, compute billing, and current preview restrictions.
For applications with growing datasets and changing compute requirements, independent scaling can simplify capacity planning. The right decision still depends on workload characteristics, feature requirements, operational constraints, and the total cost of running the database.
Join the conversation! Your thoughts help the community grow.