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.
Capacity constraints can affect creating or resuming a cluster, scaling a cluster, or adding nodes or shards. If the required resources are unavailable for the requested deployment shape, an operation may be delayed, fail, or remain in progress.
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. Atlas reevaluates the preferred hardware type only when processing a subsequent scaling request. If that hardware is available, Atlas may move the cluster back to it; Atlas does not periodically reevaluate capacity or initiate a hardware change between scaling operations (Adaptive Capacity is currently available on Azure.
Rollout timing with other cloud providers will be shared as timing is finalized.) Adaptive Capacity can reduce the impact of unavailable hardware, but it does not guarantee that a change will succeed. Using alternative hardware may affect performance. See the Adaptive Capacity documentation for additional details.
Atlas Gen2 hardware: Atlas has introduced Gen2 hardware on AWS and GCP. These newer processors are generally better stocked and can offer improved price-performance, but capacity is not guaranteed. Gen2 clusters may also face capacity constraints in severely constrained regions. Customers can choose them for new clusters or move existing clusters to them; this is an explicit customer choice rather than an automatic migration. See the Change a Cluster's Generation documentation for more information.
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.
Pre-scaling is not guaranteed if capacity at the target tier is unavailable, and it can increase costs. Auto-scaling may also fail if provider hardware is unavailable when it triggers.
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. If a capacity error is blocking an operation now, contact chat support or open a MongoDB Support case if your support plan includes case access.
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.