Atlas independent shard scaling and per-shard auto-scaling

Parent: Shard Key Design and Resharding as Cost Levers · Published reference · snapshot 2026-10-31

Source-anchored research for Atlas independent shard scaling and per-shard auto-scaling. 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.

Definitions

Independent tier scaling is a capacity response to workload skew. It does not by itself redistribute requests or change the shard key. This is an architectural inference from Atlas changing per-shard tiers and from independent partitioning guidance identifying uneven access as a separate design concern. (medium confidence) [source]

How it works

Independent scaling can avoid provisioning every shard for the hottest shard. MongoDB describes the resulting savings as workload-dependent; its cost guidance recommends addressing uneven traffic first and using independent shard scaling when that is impractical. (medium confidence) [source]
Atlas evaluates each independently scaling shard using replica-set auto-scaling criteria. When operational or analytics nodes meet a trigger, that node group on that shard changes tier, subject to cluster-wide constraints. (medium confidence) (verified as of 2026-10-14) [source]

Problems, failure modes and limitations

The April 2026 Atlas changelog announces removal of the two-tier zone gap at cluster level and support for asymmetric auto-scaling ranges. This announcement conflicts in scope with operational pages that still state cluster-wide min/max bounds and a two-tier gap between largest and smallest shards; those limits cannot safely be presented as universally settled. (medium confidence) (verified as of 2026-10-14) [source]

Comparisons and alternatives

When independent shard scaling is enabled, Atlas evaluates each shard independently; qualifying operational or analytics nodes on that shard change tier. This is compute-tier scaling, rather than automatic addition of shards. (high confidence) (verified as of 2026-10-14) [source]
The CLI exposes --autoScalingMode independentShardScaling; its independent schema uses one replicationSpecs entry per shard, rather than numShards to define the shard count. The Kubernetes API likewise describes replicationSpecs as one object per shard. (high confidence) (verified as of 2026-10-14) [source]
Inference for cost planning: per-shard compute sizing can reduce excess compute allocated to quieter shards compared with uniformly sizing all shards for the hottest shard. The cited sources establish the mechanism and workload-skew rationale, not a measured saving or guaranteed percentage. (medium confidence) [source]
Cost planning should measure request load and resource demand per shard rather than treating stored byte counts as a proxy for demand. Microsoft describes smaller, frequently accessed shards and larger, lightly accessed shards; Google independently warns that uneven traffic can overload one shard while others remain underused. These are general partitioning principles, not evidence of Atlas-specific auto-scaling behavior. (high confidence) [source]
The Atlas CLI documents --autoScalingMode independentShardScaling for independent mode and defaults to clusterWideScaling when the option is omitted. Its independent schema represents each shard with a separate replicationSpecs entry instead of numShards; the Terraform resource also imports the per-shard schema. (medium confidence) (verified as of 2026-10-14) [source]

Facts and statements

Atlas supports choosing different compute tiers per shard through the Administration API, Atlas CLI, or Terraform, allowing compute allocation to follow each shard’s workload. (high confidence) (verified as of 2026-10-14) [source]
Independent shard scaling lets Atlas Core shards use different compute tiers. Electable and read-only nodes share a tier within a shard, while analytics nodes can use a different tier; equivalent node groups on other shards can use different tiers. (high confidence) (verified as of 2026-10-14) [source]
Independent compute tiering does not imply independent storage capacity: the sharding guide requires equal storage capacity and equal node counts by role across ordinary shards; the Terraform resource also requires equal disk_size_gb across shards and node types. (high confidence) (verified as of 2026-10-14) [source]
The Atlas UI can enable compute auto-scaling for independent shard scaling, but manual per-shard tier selection uses API, CLI, or Terraform. The sharding guide warns that a UI tier change applies to all shards. (low confidence) (verified as of 2026-10-14) [source]
Do not infer a universal default from the compute guide: it says independent scaling is enabled by default for sharded clusters with auto-scaling, whereas the CLI guide says omitting --autoScalingMode defaults to clusterWideScaling. (medium confidence) (verified as of 2026-10-14) [source]
The compute auto-scaler maintains at most a two-tier gap between the largest and smallest shards. Scaling up the largest shard can therefore also force smaller shards upward, limiting how much idle-shard capacity can be reduced. (medium confidence) (verified as of 2026-10-14) [source]
The documented minimum and maximum auto-scaling tiers apply at cluster level. The sharding guide also disallows enabling per-shard auto-scaling across different cluster classes, such as General and Low-CPU. (low confidence) (verified as of 2026-10-14) [source]
Independent compute tiers do not imply independent storage capacity: the sharding guide requires the same storage capacity on all shards, and the cluster management guide requires equal disk size on all nodes of every shard. (medium confidence) (verified as of 2026-10-14) [source]
Manual tier selection per shard is available through the Atlas Administration API, Atlas CLI, or Terraform. Changing the tier of a sharded cluster in the Atlas UI changes all shard tiers, so UI edits can erase intended tier asymmetry. (medium confidence) (verified as of 2026-10-14) [source]
The Atlas management guide excludes NVMe clusters from independent shard scaling, and the compute auto-scaling guide excludes the Local NVMe SSD class from cluster-tier auto-scaling. (medium confidence) (verified as of 2026-10-14) [source]
For new shards added after predictive auto-scaling is active, Atlas documents a two-week workload-learning period before predictive scaling begins; those shards use reactive scaling in the meantime. (low confidence) (verified as of 2026-10-14) [source]
The Terraform provider documentation warns that use_effective_fields has no effect on clusters with multiple replication_specs entries. Its update path correlates shards by list position, so adding, removing, or reordering entries can associate configuration with a different shard. Keep existing entries in order and append new shards without changing existing entries in that update. (low confidence) (verified as of 2026-10-30) [source]

Children

Per-shard compute tier bounds and cascading scale-ups (frontier)
Atlas CLI independent scaling schema selection (frontier)
Terraform multi-shard auto-scaling reconciliation (frontier)

Frontier under this node: Atlas CLI independent scaling schema selection, Per-shard compute tier bounds and cascading scale-ups, Terraform multi-shard auto-scaling reconciliation

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