Atlas Infinite fixed-IOPS tiers and decoupled storage
Parent: Cluster Tier Limits and Feature Gates as Cost Drivers (Connections, IOPS Caps, Minimum Tiers) · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-b7c969c2a118
↓ Facts as markdownall context files
Source-anchored research for Atlas Infinite fixed-IOPS tiers and decoupled storage. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- Atlas Infinite separates compute, which executes queries, transactions and aggregations, from managed durable storage. Compute scaling and failover reuse the storage layer without copying the underlying dataset to new compute nodes. (high confidence) (verified as of 2026-10-14) [source]
- The published public-preview General tier reference pairs are M10: 625 IOPS/10 MBps; M20: 1,250/20; M30: 5,000/80; M40: 9,375/150; M50: 18,750/300; M60: 37,500/600. Low-CPU pairs are M40: 5,000/80; M50: 9,375/150; M60: 18,750/300. These are storage-layer specifications, not application operations per second. (low confidence) (verified as of 2026-10-14) [source]
- Atlas Infinite provides storage-layer read/write IOPS, read/write latency, bytes read/written per second, and throughput utilization. The metrics documentation marks Cache Activity, Cache Ratio, and Tickets Available as Core-only and unavailable on Infinite. Diagnostic dashboards must account for this edition difference. (low confidence) (verified as of 2026-10-14) [source]
Measurements and reference values
- MongoDB qualifies Infinite storage IOPS as baseline reference values assuming 16 kB I/O; achievable maximum IOPS vary with workload characteristics. Treating the table as a guaranteed application throughput benchmark is unsupported. (low confidence) (verified as of 2026-10-14) [source]
- TechTarget explicitly attributes its Infinite throughput comparison to tests conducted by MongoDB, and The Weighted Average identifies the 189% throughput-per-dollar figure as an internal vendor result. Neither constitutes an independently reproduced benchmark; do not extrapolate a universal saving or expected application throughput. (medium confidence) (verified as of 2026-09-30) [source]
Problems, failure modes and limitations
- Infinite compute auto-scaling changes storage IOPS and throughput with the tier and respects the configured minimum and maximum tiers. Storage performance cannot be adjusted independently within one tier. (high confidence) (verified as of 2026-10-14) [source]
- Infinite monitoring includes storage-layer read/write IOPS, read/write latency in milliseconds, throughput in bytes per second, throughput utilization, and logical storage usage against the effective storage limit. These measurements distinguish storage performance saturation from logical-capacity exhaustion. (low confidence) (verified as of 2026-10-20) [source]
- During the documented public preview, Infinite supports M10–M60 General and M40–M60 Low-CPU tiers; users cannot switch an existing cluster between Core and Infinite or change its cloud provider or region. Capacity decoupling does not remove deployment and migration restrictions. (high confidence) (verified as of 2026-10-14) [source]
- For architecture diagrams, ByteDiagram recommends separate compute and durable-storage bands, with a preview-limit annotation. This is an independently authored visualization method; the architecture and preview facts it illustrates still originate with MongoDB. (low confidence) (verified as of 2026-09-30) [source]
Comparisons and alternatives
- Atlas documents some familiar node-level metrics as Atlas Core only and unavailable on Infinite because of its decoupled storage architecture. Troubleshooting dashboards must check metric applicability instead of interpreting an unavailable node metric as evidence of zero storage activity. (medium confidence) (verified as of 2026-10-14) [source]
- Inference for sizing: capacity decoupling can avoid a compute upgrade caused solely by dataset growth, but an I/O-bound workload can still need a larger compute tier to obtain more storage throughput. Evaluate working-set access and latency rather than treating maximum logical capacity as a performance promise. (medium confidence) (verified as of 2026-10-23) [source]
- Infinite delegates replication and failover coordination to the storage layer and uses a primary plus one electable standby. Majority write concern refers to a majority within storage rather than a majority of compute nodes. Replication analysis must therefore distinguish storage acknowledgment from compute-node topology. (low confidence) (verified as of 2026-10-23) [source]
Facts and statements
- During public preview, Infinite storage capacity grows independently of the cluster tier, but storage IOPS and throughput are fixed by that tier. Growing the dataset does not increase either performance allowance; changing storage performance requires changing the tier. The UI displays these allowances as read-only values. (high confidence) (verified as of 2026-10-23) [source]
- COMPASS-10970 records a concrete tooling mismatch: Compass/Data Explorer needed to hide storage-size displays and disable rolling index builds for Infinite clusters. The task was resolved on August 24, 2026 with fix version 1.49.15; this is evidence of a historical UI compatibility issue, not proof that every deployed client is fixed. (low confidence) (verified as of 2026-08-24) [source]
- In TechTarget's September 29 reporting, Omdia analyst Stephen Catanzano characterizes Infinite as addressing demand spikes through elasticity. This is an external analyst assessment, not an independent measurement of scaling time, storage IOPS, or cost. (low confidence) (verified as of 2026-09-29) [source]
Children
- No children recorded.