Overview
Cloud infrastructure capacity is tightening across the industry as demand for compute, memory, and electricity continues to outpace supply. The impact is uneven by provider, region, hardware family, and cluster size, but the customer experience is consistent: a request that once could be provisioned or scaled on short notice may now require earlier planning and more flexibility.
MongoDB is responding on two fronts: expanding the set of hardware Atlas can use and working directly with customers and cloud providers to plan for time-sensitive capacity needs. Our goal is to preserve the elasticity customers expect while giving them practical options when a preferred hardware type is constrained.
What this means
In practice, this is changing how our cloud infrastructure partners manage capacity. Rather than freely granting new capacity on demand, providers are increasingly prioritizing workloads who utilize the available capacity immediately, tightening the process for approving new capacity and quota requests, steering toward their newest hardware generations, and limiting new reservations.
These changes mean “spinning up more capacity on demand” is no longer something any provider can guarantee instantly — a meaningful shift heading into a seasonally high-demand period for many of our customers.
Technology: more ways to find capacity
Adaptive Capacity: When a requested instance type is temporarily unavailable, Atlas can automatically use an eligible alternative with comparable characteristics—for example, substituting a compatible family from the same provider while preserving the cluster’s vCPU and memory profile. When capacity recovers, Atlas can return the cluster to its preferred hardware. (Adaptive Capacity is currently available on Azure. Rollout timing with other cloud providers will be shared as timing is finalized.)
New-generation hardware: Atlas has introduced next-generation hardware on AWS and GCP. These newer processors are generally better stocked and offer improved price-performance. Customers can choose them for new clusters or move existing clusters to them; this is an explicit customer choice rather than an automatic migration.
Run Anywhere: Customers can distribute workloads across regions, add nodes in another provider or region, or move a cluster to another provider when a particular location is constrained. This gives Atlas customers more options than a database tied to a single hyperscaler or region.
What customers should do now
Plan earlier for known events. Share projected scale-up, scale-down, migration, or provisioning dates as soon as they are known.
Pre-scale when the event is business-critical. For BFCM and similar peaks, proactive scaling is currently the most reliable way to avoid a capacity constraint during a business-critical period.
Engage MongoDB before the capacity error. On-demand capacity is volatile and may not be available for a specific date; early engagement gives the teams more options to coordinate.
Provide a precise deployment profile. Include provider, region, target tier, topology, node/shard counts, storage requirements, and the exact date capacity is needed.
Consider alternate hardware and locations. Gen2 hardware, another region, or another provider may materially improve the available options.