# Atlas independent shard scaling and auto-scaling > Source-anchored research for Atlas independent shard scaling and auto-scaling. Run status: COMPLETED. Parent: [Shard Key Design and Resharding as Cost Levers](https://llms-explorer.com/tree/shard-key-design-and-resharding-as-cost-levers/) · 6 facets · 16 facts · page: https://llms-explorer.com/tree/atlas-independent-shard-scaling-and-auto-scaling/ ## Definitions - Auto-scaling is not instantaneous protection against a sudden bulk workload: Atlas must prepare backing resources, so the compute guide recommends scaling ahead of such spikes. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core.md) ## How it works - Independent shard scaling lets Atlas allocate higher compute tiers to hot shards without uniformly raising every shard; MongoDB recommends first trying to distribute traffic evenly and using independent scaling when that is impractical. Savings depend on the workload. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding.md) ## Measurements and reference values - The compute guide requires sustained low utilization before downscaling: operational CPU below 45%, current WiredTiger cache below 90%, and projected lower-tier memory below 60%, with both 10-minute and four-hour checks. It also imposes 24-hour scale-down/provisioning/unpause and 12-hour node-restart exclusions. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core.md) ## Problems, failure modes and limitations - Independent compute tiers do not imply independently sized disks: Atlas requires equal storage capacity across shards. It also requires matching node counts by type, with a per-zone exception for Global clusters, and equal NVMe tiers; autoscaling cannot span different cluster classes. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding.md) - Manual per-shard scaling uses the Atlas Administration API, CLI, or Terraform. The Atlas UI can enable independent compute autoscaling, but cannot manually scale each shard independently; changing tier in the UI changes all shard tiers. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding.md) - Crossplane provider issue #191 reports storage autoscaling causing a repeated DISK_SIZE_GB_TOO_SMALL reconciliation failure: initProvider disk size was merged back into updates after Atlas enlarged the disk. Maintainers linked an Upjet update and closed the issue as completed on October 21, 2026; this is a controller-specific historical failure, not proof that current Atlas autoscaling is broken. (low confidence) (verified as of 2026-10-21) — [source](https://github.com/crossplane-contrib/provider-mongodbatlas/issues/191) - Storage capacity and electable, read-only, and analytics node counts must match across shards, with a per-zone node-count exception for Global clusters. Auto-scaling bounds apply cluster-wide, and mixed cluster classes cannot use per-shard auto-scaling. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding.md) ## Comparisons and alternatives - Within an Atlas shard, electable and read-only nodes share a compute tier; analytics nodes can use a different tier. Both groups can differ from their counterparts on other shards. (high confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding.md) - PointFive recommends ranking waste using replica count and shard count, because its billing model multiplies data-bearing nodes by both. This supports assessing tier changes across the full replicated deployment rather than treating one shard as one billed node. (low confidence) (verified as of 2026-10-30) — [source](https://www.pointfive.co/efficiency-hub/inefficiencies/overprovisioned-mongodb-atlas-cluster-tier) ## Facts and statements - Atlas Core autoscaling evaluates shards independently, but the smallest shard must remain within two tiers of the largest. Upscaling the largest can therefore also upscale smaller shards. Minimum and maximum autoscaling tiers apply cluster-wide. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core.md) - The sharding guide says clusters created before December 9, 2024 default to cluster-wide scaling; automation clients need upgrades, and UI-managed clusters with compute auto-scaling may require MongoDB support to enable independent scaling. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/cluster-sharding.md) - Reactive scaling needs provisioning time and may miss sudden bursts; pre-scale for known bulk loads. Predictive scaling handles recurring demand and only scales up; downscaling remains reactive. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core.md) - Treat autoscaling bounds and sustained utilization as cost controls. Mydbops recommends explicit bounds and ongoing review; Atlas requires sustained low CPU and projected memory utilization plus cooldown conditions before downscaling, so a brief drop in traffic does not guarantee immediate savings. (medium confidence) (verified as of 2026-08-07) — [source](https://www.mydbops.com/blog/how-to-reduce-mongodb-atlas-costs-at-scale) - Atlas Infinite public preview does not support sharded clusters or independent/asymmetric shard autoscaling. Its decoupled compute and storage architecture must not be presented as equivalent to independent Atlas Core shard scaling. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing.md) - Per-shard operational and analytics node groups can change tiers separately. Config-server replica sets do not auto-scale, whereas a config shard does. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core.md) - Mydbops recommends explicit auto-scaling tier bounds; PointFive recommends enabling scale-down and placing the minimum below the current tier. Together these are operational controls against remaining overprovisioned after peaks, not evidence of a measured savings percentage. (medium confidence) (verified as of 2026-08-07) — [source](https://www.mydbops.com/blog/how-to-reduce-mongodb-atlas-costs-at-scale)