Cluster Tier Limits and Feature Gates as Cost Drivers (Connections, IOPS Caps, Minimum Tiers)

Published reference · snapshot 2026-10-20 · skill mongodb-operations-expert/references/cluster-tier-limits-and-feature-gates-as-cost-drivers-connections-iops-caps-minimum-tiers.md · viability 3.45 / 5 (research)

Also known as: Three-node minimum for non-production

↓ Facts as markdown all context files

Source-anchored research for Cluster Tier Limits and Feature Gates as Cost Drivers (Connections, IOPS Caps, Minimum Tiers). 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.

How it works

Connection limits apply per node. In a sharded cluster they apply per mongos router, and the router count equals the number of replica set nodes across all shards. Atlas reserves 10 connections per node for its own services. A three-node M10 with 1,500 per node can serve 2,980 connections from its two secondaries when the read preference is secondary. (low confidence) (verified as of 2026-10-20) [source]
Atlas states that cluster connection limits are enforced for AWS only when clients connect over private link, on MongoDB 8.1 and 8.1.0 or later, 8.0 and 8.0.10 or later, and 7.0 and 7.0.22 or later. The page does not say how limits apply on other AWS connection paths. (low confidence) (verified as of 2026-10-20) [source]
M10 and M20 run on burstable-performance infrastructure on AWS, Azure and Google Cloud. Atlas warns that cloud providers cap CPU after burst periods, so heavy load causes throttling. MongoDB describes M10 and M20 as shared-vCPU tiers, and M30 as the first tier with dedicated vCPUs and the recommended tier for production. (high confidence) (verified as of 2026-10-14) [source]
MongoDB Search and Vector Search run on Free, Flex and M10+ clusters with the mongot process on the same node as mongod. Dedicated Search Nodes need an M10+ cluster. Atlas enforces a minimum of two Search Nodes (maximum 32 per region per shard) and bills each node hourly. Google Cloud supports Search Nodes in all regions, AWS and Azure in a subset. MongoDB notes that sharing a node can cost less than separate nodes but may cause resource contention, so it recommends separate Search Nodes for production. (high confidence) (verified as of 2026-10-14) [source]
The System: CPU (Steal) % alert fires when usage exceeds the baseline CPU credit accumulation rate and the EC2 credit balance is exhausted. Atlas triggers it only for AWS EC2 burstable instances, currently M10 and M20. Atlas does not show baseline utilization in its metrics, so credit headroom is not directly visible. (medium confidence) (verified as of 2026-10-14) [source]
On M40 and larger AWS clusters without NVMe, Atlas can temporarily provision a higher-performance volume when it replaces or adds a node (fast disk pre-warming). The extra disk cost lands on that month's bill, so storage cost can exceed expectations in months with node replacement. (high confidence) (verified as of 2026-10-18) [source]
Atlas can cap configurable IOPS below the maximum AWS lists for the underlying instance type, because some higher rates can be sustained only briefly and Atlas prioritizes high availability. (low confidence) (verified as of 2026-10-14) [source]
In the Atlas Administration API and CLI, Gen2 tiers carry a _GEN_2 suffix (M30_GEN_2). Passing a bare Gen1 name such as M200 when updating a Gen2 cluster can unintentionally change its generation. (low confidence) [source]
Buying IOPS by enlarging the disk is costly: when you customize storage Atlas bills the full storage amount without deducting the tier's default storage, and on Gen1 storage and IOPS scale together so the bill reflects both. (medium confidence) (verified as of 2026-10-14) [source]
Average Disk IOPS graphs can hide throttling: a practitioner saw multi-second write stalls on a small Azure M20 while the average graph looked idle, until Atlas added max-value metrics in Oct 2021. Atlas pairs each hardware metric with a burst-reporting alert, and lists raising IOPS, storage or tier as the fixes when usage exceeds configured IOPS. (medium confidence) [source]

Measurements and reference values

The pricing tables list M10 as 2 vCPUs on AWS, 1 on Azure and 0.5 on Google Cloud. M20 is 2, 1 and 1. M30 is 2 on all three. Google Cloud lists M10 with 1.7 GB RAM and M20 with 3.75 GB, against 2 GB and 4 GB on AWS and Azure. The same tier name does not mean the same hardware across clouds. (low confidence) (verified as of 2026-10-14) [source]
Free clusters allow 100 operations per second, 500 connections and 0.5 GB (512 MB) of data. They throttle after 10 GB in and 10 GB out per rolling seven days. Atlas pauses a Free cluster after 30 days with zero connections. Free clusters have no backups, network peering, private endpoints or database auditing. (high confidence) (verified as of 2026-10-14) [source]
Leaving Flex for the first Dedicated tier roughly doubles the monthly floor. Flex tops out at $30 per month at 500 ops per second. M10 on AWS us-east-1 is $0.08 per hour, which the pricing page estimates at $57 per month. M10 also raises the connection ceiling from 500 to 1,500 per node. (medium confidence) (verified as of 2026-10-14) [source]
M30 and larger clusters start at 3,000 standard IOPS. This matches the 3,000 IOPS baseline that an EBS gp3 volume includes in its storage price. On Gen2 the baseline stays 3,000 below 1,000 GB of disk and then rises 3 IOPS per GB (2,000 GB gives 6,000; 4,000 GB gives 12,000). (medium confidence) (verified as of 2026-10-18) [source]
Atlas enforces a disk-to-RAM ratio of 60:1 for M10 to M40 and 120:1 above M40, so data size can force a larger tier: 3 TB needs at least 32 GB of RAM (M50 or larger). The pricing table's storage maxima fit these ratios: M40 (16 GB RAM) up to 1 TB; M50 (32 GB RAM) up to 4 TB. (medium confidence) (verified as of 2026-10-14) [source]
Local NVMe tiers (M40 and larger; AWS and Azure only, not Google Cloud) have fixed storage per tier, for example 380 GB on AWS M40_NVMe and 760 GB on M50_NVMe. They auto-scale to the next tier when 90% of storage is used. Gen1 NVMe clusters must use standard IOPS. (high confidence) (verified as of 2026-10-18) [source]
Atlas Infinite public-preview storage performance by tier (16 kB I/O reference values): M10 625 IOPS and 10 MBps; M20 1,250 and 20; M30 5,000 and 80; M40 9,375 and 150; M50 18,750 and 300; M60 37,500 and 600. Low-CPU: M40 5,000 and 80; M50 9,375 and 150; M60 18,750 and 300. (low confidence) (verified as of 2026-10-18) [source]
If you customize storage, Atlas bills the full custom size and does not credit the default storage. Example: an M10 raised from 10 GB to 50 GB bills for 50 GB. Changing class, for example General to Low-CPU, has the same effect. (low confidence) (verified as of 2026-10-18) [source]
For M10 and M20, Atlas judges scale-up on Relative System CPU Utilization, which is Normalized System CPU divided by baseline CPU utilization, capped at 100%. On AWS it scales up when relative utilization stays above 90% for 20 minutes and CPU steal stays above 30% for 3 minutes, or when other listed conditions hold. Scale-down needs Normalized System CPU below 45% of baseline (about 9% absolute at a 20% baseline) over the last 10 minutes and 4 hours. (low confidence) (verified as of 2026-10-19) [source]
On MongoDB's feedback portal, users have asked since June 2022 for CPU-credit metrics on M10 and M20 (status Submitted, no staff reply visible). A July 2025 comment reports an M20's CPU Steal % rising from 0% to 80% within minutes, which the commenter calls effectively a denial of service. (low confidence) (verified as of 2026-10-20) [source]
Free and Flex clusters both cap at 500 connections. Free also caps at 100 operations per second and 0.5 GB of data; Flex caps at 500 operations per second and 5 GB. (high confidence) (verified as of 2026-10-14) [source]
Atlas caps disk size by RAM: the docs give a disk-to-RAM ratio of 60:1 for M10-M40 and 120:1 above M40 (the section is titled 'Minimum Disk Capacity to RAM Ratios'), so 3 TB needs at least 32 GB of RAM, which means M50 or larger. The listed storage maxima follow: M10 128 GB, M20 about 256 GB, M30 512 GB, M40 1 TB, M50 4 TB. (high confidence) (verified as of 2026-10-14) [source]
On Atlas Core clusters storage IOPS scale with disk size. Gen1 AWS standard IOPS start at 3,000 on M30+ and scale 3:1 per GB only from 1 TB, up to 16k. Gen2 (M30+, AWS and Google Cloud only) has a 3,000 baseline below 1,000 GB, 3:1 above, and Extended Standard IOPS up to 80k on AWS and 160k on Google Cloud, billed separately from storage. (high confidence) (verified as of 2026-10-14) [source]
Fixed storage IOPS and throughput per Atlas Infinite tier (AWS reference): M10 625 IOPS and 10 MBps, M20 1,250 and 20, M30 5,000 and 80, M40 9,375 and 150, M50 18,750 and 300, M60 37,500 and 600; Low-CPU variants get lower values. (low confidence) (verified as of 2026-10-14) [source]
Outside Enterprise and Platinum plans, Atlas adds a 10% uplift to the hourly cost of dedicated clusters in projects that use Database Auditing, and a 15% uplift to each cluster with LDAP authentication or customer-key encryption at rest. Customer-managed keys also incur the cloud provider's KMS request charges. (medium confidence) (verified as of 2026-10-18) [source]
Co-located search (mongod and mongot on the same node) suits Free, Flex or M10-M20 testing only below roughly 2M documents, 10 GB of indexed data and 10,000 queries per 7 days; beyond that Atlas says to migrate to dedicated Search Nodes. Co-located processes can contend for resources. (low confidence) (verified as of 2026-10-18) [source]
By default, clusters of M30 or smaller give WiredTiger 25% of RAM for its cache, while M40 and larger give 50% or more. That is about 2 GB of cache on an 8 GB M30 against 8 GB on a 16 GB M40, a 4 times jump for 2 times the RAM. (low confidence) (verified as of 2026-10-14) [source]
Running sustained load on M10 or M20 exhausts burstable CPU credits. A practitioner running M20 on Azure reports a B-series VM with a 40% CPU baseline and no CPU Steal metric or alert on Azure, which matches the Atlas doc that the alert covers only AWS burstable instances. (medium confidence) [source]
Configuring LDAP for a project enables it for every cluster in that project, while customer-key encryption at rest can be switched on per cluster, so the 15% uplift follows the project for LDAP but the individual cluster for customer keys. (low confidence) (verified as of 2026-10-18) [source]

Problems, failure modes and limitations

Atlas sets the maximum concurrent incoming connections by cluster tier, storage class and cloud. General-class per-node limits: Free and Flex 500; M10 1,500; M20 3,000; M30 3,000. When a node reaches its limit, it opens no new connections until open connections drop below the limit. (high confidence) (verified as of 2026-10-14) [source]
Atlas auto-scaling responds to memory and compute use, not to connection counts. A connection limit alone does not raise the tier. The documented scale-up criteria are CPU, memory, and queued or rejected operations. The documented ways past a connection limit: tune the application, enable connection pooling, enable auto-scaling for the load the connections cause, or scale the tier permanently. (medium confidence) (verified as of 2026-10-19) [source]
On AWS T-family burstable instances, the instance earns CPU credits at a fixed rate and spends them above a baseline utilization. Baseline per vCPU is 20% for t3.small and t3.medium, 30% for t3.large, and 40% for t3.xlarge and t3.2xlarge. In standard mode, an instance with no accrued credits drops gradually to baseline and cannot burst until it accrues credits. Atlas puts baseline at about 20% to 50% for burstable types and does not show it in Atlas metrics. (high confidence) [source]
Flex clusters cap read and write operations at 500 per second, allow 500 connections and 5 GB of data, and allow 100 databases and 500 collections. Above 500 ops per second Flex enforces a hard limit with a sub-second cooldown and queued operations, not a higher price tier. Flex bills usage tiers from $0.011 per hour (up to 100 ops per second, $8 per month) to $0.0411 per hour (400 to 500 ops per second, $30 per month). (high confidence) (verified as of 2026-10-14) [source]
Tier moves toward Flex are blocked. Atlas lets you scale a Free cluster to Flex or Dedicated at any time. It does not let you scale an M10+ Dedicated cluster down to Free or Flex, and you cannot change a cluster's database edition (Atlas Core or Atlas Infinite) after creation. (medium confidence) (verified as of 2026-10-20) [source]
Atlas allows sharded clusters only on M30 or larger. Converting a replica set to a sharded cluster cannot be reversed. M10 and M20 support replica sets only. (high confidence) [source]
Global Writes requires an M30 or larger sharded cluster, or a replica set scaled to at least M30. You cannot disable Global Writes after you enable it. While Global Writes is on, Global Clusters do not support dedicated Search Nodes. Flex clusters do not support Global Clusters. (high confidence) [source]
On AWS, M30 and larger clusters can buy Provisioned IOPS (Gen1) or High Performance IOPS (Gen2). These use Provisioned IOPS SSD volumes, designed to deliver the provisioned rate 99.9% of the time, against 99% for the General Purpose SSD behind standard IOPS. Custom storage speed raises cost. For Gen1 the allowed range depends on disk size; for Gen2 it does not. Gen1 NVMe clusters cannot customize IOPS. (high confidence) (verified as of 2026-10-18) [source]
Instance size caps disk IOPS regardless of what you provision. On AWS, EBS performance is bounded by the lower of the instance type's limit and the attached volumes' aggregate. Smaller sizes sustain their maximum for only 30 minutes at least once per 24 hours, then revert to baseline (per the AWS table, m5.large: baseline 3,600, maximum 18,750 IOPS). On Azure, VM size sets IOPS and throughput limits apart from disk limits, so a Standard_D2s_v3 cannot reach a P30 disk's 5,000 IOPS. Atlas adds that AWS-listed instance maximums can exceed what Atlas lets you configure. (high confidence) (verified as of 2026-09-16) [source]
Atlas recommends at most 5,000 combined collections and indexes on M10, 10,000 on M20 and M30, and 100,000 on M40 and larger. Above that, checkpoints take longer, operations slow, and operations can stall at the ulimit. Atlas suggests a larger tier to raise the limit. (low confidence) (verified as of 2026-10-20) [source]
On Azure, IOPS rise with disk size at no extra charge. Extra IOPS cost more, are available on M40 and larger in regions that support extended storage, and cannot exceed the tier's maximum. (medium confidence) (verified as of 2026-10-18) [source]
Atlas Infinite in public preview does not support sharded clusters, Online Archive, dedicated Search Nodes, Global Writes or Extended Standard IOPS, and a cluster cannot change database edition after creation. (high confidence) (verified as of 2026-10-14) [source]
Atlas documents these steps when a cluster nears its connection limit: fix code that opens connections and never closes them, enable driver connection pooling, enable cluster auto-scaling, and scale the tier. The 'Connections % of configured limit' alert warns before the limit. Free and Flex clusters can alert only on Connections, Logical Size, Network and Opscounter. (high confidence) [source]
For immediate relief at the connection limit on M10 and larger clusters, Test Primary Failover steps down the primary and drops all its connections. If the application connects only to a secondary, repeat it until that node rotates, or restart the application. Free and Flex connect through a proxy that enforces the IP access list on active connections, so clearing all access list entries drops them. (low confidence) [source]
A November 2020 MongoDB Community thread reports a Vercel/Lambda user hitting the Atlas connection limit when functions scaled up. MongoDB staff advised a reasonable connection pool limit and creating the client outside the handler. The poster said pool tuning helped only at small scale. (low confidence) [source]
On Azure clusters that support extended storage and IOPS, Atlas allows up to four disk IOPS or throughput changes in any 24-hour period. At the limit, Atlas replaces the virtual machine to get around it. (low confidence) (verified as of 2026-10-18) [source]
Buying IOPS beyond what the instance can move wastes money, because the instance cap applies whatever the disk provisions (AWS EBS-optimized limits; Azure VM limits). Check the instance's EBS or VM IOPS limit before raising provisioned IOPS. (high confidence) [source]
Atlas derives the maximum number of concurrent incoming connections from the cluster tier and storage class (it sets net.maxIncomingConnections), and the limit applies per node, not per cluster. (high confidence) [source]
On sharded clusters the connection limit applies per mongos router, and Atlas runs one mongos per replica-set node across all shards. The docs' worked example, a three-node M10 with 1,500 connections per node and 10 reserved per node, gives a combined 2,980 when reads go to the two secondaries. (low confidence) [source]
Atlas also rate-limits new connections per second per node (General class): M10 15, M20 15, M30 24, M40 85, M50 170, M60 320, M80 1,000. The limit is always on for M10 and M20, and for M30 and up only on MongoDB 9.0 or later. At the limit Atlas queues new connection attempts, and sustained overload makes it drop some connections. (low confidence) (verified as of 2026-10-14) [source]
Flex pricing runs from $8 for the base tier (up to 100 operations per second, 5 GB included) to $30 per 30 days at 400-500 operations per second, billed hourly. There is no price tier above 500 operations per second; Atlas applies a hard throughput limit instead. (high confidence) (verified as of 2026-10-14) [source]
MongoDB's guidance for approaching the connection limit lists tuning the application, enabling connection pooling, and enabling cluster auto-scaling before a permanent tier upgrade. Atlas scales on memory and compute use, not on connection counts, and the connection-alert page calls alerts generally a symptom of a larger problem such as connections that are opened but never closed. (high confidence) [source]
Creating a MongoClient per request or Lambda invocation multiplies connection pools and causes connection storms that can pass for a capacity shortage. In one forum case an M30 at 95% of its 3,000 limit was upgraded to M40 and connections still peaked at 3-4.5K; the thread reached no confirmed resolution. (medium confidence) [source]
When clients exceed the tier limit Atlas can refuse new connections with the error 'connection refused because too many open connections', and the 'Connections % of configured limit' alert fires. Compare connections.current with the tier's per-node limit before concluding you need a bigger tier. (high confidence) [source]
To shed connections quickly, restart the application; on M10+ run Test Primary Failover, which drops all connections to the primary (repeat it if the app reads from a secondary). Flex clusters cannot run failover tests, and Free and Flex connect through a proxy that enforces the IP access list on active connections. (medium confidence) [source]
A Flex cluster that reaches 500 operations per second is throttled, not billed more: Atlas applies a sub-second cooldown on each connection and queued operations can wait over a second. Flex workloads that regularly hit this limit or the 5 GB storage limit should consider Dedicated. (high confidence) (verified as of 2026-10-18) [source]

Comparisons and alternatives

Atlas Infinite (public preview) supports only M10-M60 tiers and fixes storage IOPS and throughput per tier instead of scaling them with disk size, so changing IOPS means changing tier. It lists from $0.09/hr against $0.08/hr for a Core M10. (high confidence) (verified as of 2026-10-14) [source]
Atlas exposes the signals that show a tier limit biting: the 'Connections % of configured limit' alert and Connections chart, 'Disk read/write IOPS on Data Partition' alerts, the Disk IOPS graph compared with configured IOPS, IOWait in Normalized System CPU, and the CPU (Steal) % alert on AWS M10/M20. (high confidence) [source]

Facts and statements

Storage class and cloud change the connection ceiling. On AWS, Low-CPU M40 allows 4,000 connections per node against 6,000 for General M40; on Azure and Google Cloud, Low-CPU M40 allows 6,000. Low-CPU tiers carry half the vCPUs of the General tier of the same size and may carry fewer maximum connections. (medium confidence) (verified as of 2026-10-18) [source]
Moving from M20 to M30 raises no connection ceiling: both list 3,000 per node in the General class. The first step up is M40 at 6,000. On AWS us-east-1 the base price rises from $0.20 per hour (M20) to $0.54 (M30), then to $1.04 (M40). (medium confidence) (verified as of 2026-10-14) [source]
AWS us-east-1 General-class ladder, base price per hour (default storage included) and per-node connection ceiling: M10 $0.08, 1,500; M20 $0.20, 3,000; M30 $0.54, 3,000; M40 $1.04, 6,000; M50 $2.00, 16,000; M60 $3.95, 32,000; M80 $7.30, 96,000. (medium confidence) (verified as of 2026-10-14) [source]
Atlas also caps new connections per second per node. General class: M10 15; M20 15; M30 24; M40 85; M50 170; M60 320; M80 1,000; M140 1,360; M200 1,450; M300 1,600. At the cap, Atlas queues new attempts and drops some connections if overload persists. The cap is always on for M10 and M20. For M30 and larger it is on only with MongoDB 9.0 or later and off on earlier versions. By arithmetic, admitting 500 new connections at 15 per second takes about 33 seconds. (low confidence) (verified as of 2026-10-20) [source]
Atlas stopped creating M2, M5 and Serverless instances in February 2025. On January 22, 2026 it ended support, migrated all M2 and M5 clusters to Flex, and moved Serverless instances to Free, Flex or Dedicated clusters according to usage. Migrated M2 and M5 customers moved from a flat monthly price to ops-per-second pricing. (high confidence) (verified as of 2026-10-14) [source]
Sharded clusters add config servers, which run on M30 and are billed separately from the data-bearing servers. The Atlas limits page lists the config server tier as M30 for both minimum and maximum. (high confidence) (verified as of 2026-10-14) [source]
Dedicated clusters (M10 and larger) unlock features that Free and Flex lack: Cloud Backup with continuous backup and point-in-time restore (Flex has one automatic daily snapshot, no on-demand snapshots and no point-in-time restore; Free has no backups), private endpoints, network peering, database auditing, encryption at rest with customer-managed keys, the Performance Advisor, the Real-Time Performance Panel, cross-region deployment, and dedicated analytics or search nodes. (high confidence) (verified as of 2026-10-14) [source]
Online Archive is available only on M10 and larger clusters. Flex clusters do not support it. Atlas charges a fee for each archive partition a query reads, and data transferred to the federated infrastructure incurs data transfer cost. (high confidence) [source]
Gen1 dedicated clusters scale storage and standard IOPS together and top out at 16k standard IOPS on AWS and 100k on Google Cloud. Gen2 clusters (M30 and larger, AWS and Google Cloud only, no multi-cloud) scale and bill storage and IOPS independently and allow up to 80k IOPS on AWS and 160k on Google Cloud. Gen2 supports reactive auto-scaling only. (high confidence) (verified as of 2026-10-14) [source]
Atlas's Gen2 ceiling on AWS (80k IOPS) equals the current EBS gp3 maximum (80,000 IOPS, 2,000 MiB/s), and its Gen1 ceiling (16k) equals the gp2 maximum (16,000 IOPS, reached at 5,334 GiB). Atlas documents standard IOPS only as General Purpose SSD, so the volume type behind Gen2 is an inference. (medium confidence) (verified as of 2026-10-18) [source]
Extended storage lets single-region AWS Core clusters in General or Low-CPU class exceed default disk limits: M40 up to 4 TB; M50 and M60 up to 8 TB; M80 and larger up to 14 TB. Atlas warns it slows initial syncs and cross-project snapshot restores and can reduce high availability, and recommends sharding for long-term growth. (low confidence) (verified as of 2026-10-18) [source]
On Atlas Infinite (public preview) the cluster tier fixes storage IOPS and throughput, and they do not grow with data; changing performance means changing the tier. On Atlas Core, storage performance scales with disk capacity. (high confidence) (verified as of 2026-10-18) [source]
The pricing page lists Atlas Infinite as a public preview on M10+ dedicated clusters, starting at $0.09 per hour, with up to 128 TB per shard and 1M+ IOPS burst performance. (low confidence) (verified as of 2026-10-14) [source]
The Intelligent Workload Management section appears on M10 and larger clusters, but Load Shedding takes effect only on M30+ replica sets running MongoDB 9.0 or later; on M10 and M20 the setting appears and does nothing. Adaptive capacity takes effect on M30 and larger. (low confidence) (verified as of 2026-10-20) [source]
MongoDB's guidance is to start lower, monitor, and scale up; use auto-scaling on Dedicated tiers; and treat M30 and larger as the production tier. The tier is the foundational cost driver, with storage, data transfer, backups and add-ons (Search Nodes, Stream Processing, support) on top. (medium confidence) (verified as of 2026-10-14) [source]
After a Gen1 cluster switches to Gen2, it may keep more IOPS than the Gen2 baseline included with its storage. Atlas recommends re-tuning storage and IOPS separately to cut cost. Atlas bills Extended Standard IOPS beyond the baseline separately. (medium confidence) (verified as of 2026-10-18) [source]
AWS allows at most four modifications per EBS volume in a rolling 24-hour period and requires each to complete first. Atlas delays further storage or IOPS changes on that volume until AWS permits another. A 1 TiB volume can take up to six hours to modify. Atlas's fast disk pre-warming on M40 and larger non-NVMe AWS clusters consumes one of the four. (high confidence) (verified as of 2026-10-18) [source]
One practitioner running Atlas on Azure reports (2021 to 2022 observations) single small-document inserts taking up to 7 to 15 seconds, a problem that persisted after upgrading to M30 and that they attribute to Azure disk IOPS throttling. They report most issues resolved after Atlas adopted Azure Premium SSD v2 in Q4 2024. These are one customer's observations, partly relayed from support. (low confidence) (verified as of 2025-01-17) [source]
A practitioner's November 2024 table lists default IOPS per tier: M10 640 on Azure and 1,000 on AWS; M20 1,280 and 2,000; M30 3,200 and 3,000. The Atlas pages read for this research do not publish default IOPS for M10 and M20. (low confidence) (verified as of 2025-01-17) [source]
Running sustained production load on M10 or M20 risks CPU-credit throttling that looks like a node slowdown, not a connection or disk problem. Atlas documents the CPU steal alert for these tiers and recommends M30 and larger for production. (medium confidence) [source]
General-class maximum connections per node are M10 1,500, M20 3,000, M30 3,000 and M40 6,000, so M20 and M30 share one ceiling. (high confidence) (verified as of 2026-10-20) [source]
Upper General-class tiers allow M50 16,000, M60 32,000, M140 96,000, and M200 and M300 128,000 connections per node. M80 allows 96,000 on AWS but 64,000 on Azure and Google Cloud. (medium confidence) (verified as of 2026-10-20) [source]
Low-CPU tiers (M40 and up) carry half the vCPUs of the General tier of the same name and can carry lower connection caps: AWS M40 Low-CPU allows 4,000 connections per node against 6,000 for General M40, and AWS M80 Low-CPU allows 64,000 against 96,000. Azure and Google Cloud Low-CPU M40 stays at 6,000. (medium confidence) (verified as of 2026-10-20) [source]
AWS us-east-1 base prices on the Atlas pricing page are M10 $0.08/hr, M20 $0.20/hr and M30 $0.54/hr, including each tier's default storage. (high confidence) (verified as of 2026-10-14) [source]
Higher AWS us-east-1 base prices are M40 $1.04/hr, M50 $2.00/hr, M60 $3.95/hr and M80 $7.30/hr, so each step from M30 to M80 roughly doubles the price. (low confidence) (verified as of 2026-10-14) [source]
Moving from M20 to M30 adds no connection capacity (both 3,000 per node) while the AWS list price rises 2.7 times ($0.20 to $0.54 per hour); M30 to M40 doubles the cap to 6,000 for about 1.9 times the price ($1.04). This is arithmetic derived from the limits table and the price table. (medium confidence) (verified as of 2026-10-14) [source]
The AWS ceilings in Atlas match Amazon EBS general-purpose limits: Gen1's 16k equals the gp2 maximum of 16,000 IOPS (3 IOPS per GiB), and Gen2's 80k equals the gp3 maximum of 80,000 IOPS with a 3,000 IOPS baseline included in the storage price. This is an inference: the Atlas docs say standard IOPS use AWS General Purpose SSD volumes but do not name gp2 or gp3. (medium confidence) (verified as of 2026-10-14) [source]
On AWS, M10 and M20 clusters can raise IOPS only by adding storage or moving to a bigger tier. Provisioned IOPS (Gen1) and High Performance IOPS (Gen2) exist only on M30+ AWS clusters. (high confidence) (verified as of 2026-10-14) [source]
Clusters with at least 1 TB of storage have baseline IOPS at or above the maximum burst rate and never deplete burst credits; M140 and larger ship with at least 1 TB. The same threshold appears in AWS gp2, where baseline reaches the 3,000 IOPS burst ceiling at 1,000 GiB (3 IOPS per GiB). (medium confidence) (verified as of 2026-10-14) [source]
Sharding and Global Writes need an M30 or larger tier; M10 and M20 support replica sets only. Sharded clusters add three config servers on M30, the only allowed config-server tier, billed separately from the data-bearing nodes. (high confidence) [source]
Atlas clusters are always replica sets with at least three nodes, and Atlas charges the cluster tier and storage for each data-bearing node. A sharded cluster has replication factor times shard count data-bearing nodes, plus config servers. (high confidence) [source]
Flex clusters do not support private endpoints, continuous backup with point-in-time restore, sharding, database auditing, customer-key encryption at rest, network peering, Performance Advisor, or dedicated search and analytics nodes. Free clusters also lack backups. Dedicated nodes require M10 or larger. (high confidence) (verified as of 2026-10-14) [source]
Atlas recommends production search on an M10+ cluster with dedicated Search Nodes at the S20 or higher search tier. It requires at least two Search Nodes (up to 32 per region per shard) and bills each hourly, rounding partial hours up. At the S20 AWS list price of $0.12/hr per node, the two-node floor is about $0.24/hr, three times the $0.08/hr M10 base. (high confidence) (verified as of 2026-10-14) [source]
M10 and M20 run on burstable-performance infrastructure: cloud providers cap CPU after burst periods, so sustained load can throttle. Atlas recommends M30+ for production, and its CPU (Steal) % alert covers only AWS burstable instances, currently M10 and M20. (high confidence) [source]
Atlas recommends at most 5,000 combined collections and indexes on M10, 10,000 on M20 and M30, and 100,000 on M40 and up. Exceeding the figure slows checkpoints and can stall operations; the documented remedy is a larger tier. (low confidence) (verified as of 2026-10-14) [source]
Small Azure tiers deliver fewer IOPS than the same tier on AWS: a practitioner's Nov 2024 UI snapshot shows M10 at 640 IOPS on Azure and 1,000 on AWS, M20 at 1,280 and 2,000, and M30 at 3,200 and 3,000. Before Atlas moved Azure to Premium SSD v2 in Q4 2024 the Azure M20 figure was 120. (low confidence) (verified as of 2024-11-04) [source]
On M30+ clusters in AWS and Google Cloud, Gen2 lets you buy IOPS and storage independently, so an IOPS shortfall need not force a tier upgrade. After moving a Gen1 cluster to Gen2, re-tune storage and IOPS separately to stop paying for IOPS you no longer need. Gen2 is unavailable on Azure and for multi-cloud clusters, and supports only reactive auto-scaling on Atlas Core. (high confidence) (verified as of 2026-10-14) [source]
For non-production workloads Flex ($8-$30 per 30 days) undercuts the smallest Dedicated cluster, which Atlas lists as starting at $56.94 per month (about $60 in the Flex docs); Dedicated starts at M10, which is always a three-node replica set. (high confidence) (verified as of 2026-10-14) [source]
Budget connections as maxPoolSize times application servers per mongod: with the default maxPoolSize of 100, four application servers can open up to 400 connections to each node. Add monitoring overhead: MongoDB staff say each Lambda instance needs at least three connections (one for the operation, one monitoring, one round-trip-time). (high confidence) [source]
Confirm a connection storm with serverStatus: sudden growth in connections.current, connections.active or connections.totalCreated, spikes in metrics.network.totalIngressTLSHandshakeTimeMillis, and rising failed-command counts. On Atlas read Metrics > Connections. Raising minPoolSize toward maxPoolSize pre-warms pools and smooths spikes. (medium confidence) [source]

Children

Atlas Infinite fixed per-tier IOPS and public-preview feature exclusions
Atlas Infinite fixed-IOPS tiers and decoupled storage
Atlas Search Nodes cost floor and co-located versus dedicated search (frontier, viability 4.05 / 5)
Atlas security add-on uplifts (auditing, LDAP, customer-managed keys, private endpoints)
Burstable M10/M20 CPU credits and the M30 production threshold (frontier, viability 3.63 / 5)
Burstable M10/M20 CPU-credit throttling and when to move to M30 (frontier, viability 3.63 / 5)
Connection pool sizing and connection-storm control for Atlas (serverless and Lambda clients)
Connection pooling and connection-storm control for Atlas (serverless and Lambda clients)
Dedicated Search Nodes two-node cost floor versus coupled mongot (frontier, viability 3.83 / 5)
Flex versus Dedicated boundary: ops-per-second pricing and missing features (frontier, viability 3.98 / 5)
Flex-to-Dedicated migration triggers (500 ops/sec, 5 GB, feature gates) (frontier, viability 3.83 / 5)
Gen1 versus Gen2 IOPS provisioning and instance-level EBS/VM IOPS caps (frontier, viability 4.10 / 5)
Gen2 clusters and Extended Standard IOPS economics (frontier, viability 3.52 / 5)
One-way tier gates: sharding, Global Writes, edition changes (frontier, viability 3.75 / 5)

Frontier under this node: Atlas Search Nodes cost floor and co-located versus dedicated search (4.05), Burstable M10/M20 CPU credits and the M30 production threshold (3.63), Burstable M10/M20 CPU-credit throttling and when to move to M30 (3.63), Dedicated Search Nodes two-node cost floor versus coupled mongot (3.83), Flex versus Dedicated boundary: ops-per-second pricing and missing features (3.98), Flex-to-Dedicated migration triggers (500 ops/sec, 5 GB, feature gates) (3.83), Gen1 versus Gen2 IOPS provisioning and instance-level EBS/VM IOPS caps (4.10), Gen2 clusters and Extended Standard IOPS economics (3.52), One-way tier gates: sharding, Global Writes, edition changes (3.75)

← the whole tree · 3D view· how to read this page