Destination temporary scaling and post-cutover right-sizing
Parent: Migration and Cutover Cost (Live Migration, mongosync, Dual-Running, Egress) · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Destination temporary scaling and post-cutover right-sizing. 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
- When an Atlas Core configuration change requires migration, Atlas replaces nodes in rolling order, secondaries before the primary, with shards processed independently. MongoDB warns that secondary-read workloads can lose performance because each replica set has one fewer secondary available during migration; initial synchronization can also add load to the primary. (medium confidence) (verified as of 2026-10-30) [source]
- Increasing destination index-build parallelism can increase CPU load and trigger unintended autoscaling. Observe migration-phase resource use separately from post-cutover application demand before deciding that a temporarily elevated tier is the steady-state requirement. (low confidence) (verified as of 2026-10-14) [source]
- Quest1 reports retaining an application-wide JMeter performance suite after an Atlas migration so that the platform team could validate later capacity changes. This is a first-party implementation example of reusable right-sizing verification, not independent proof of a specific optimal tier or savings amount. (low confidence) [source]
How-to and procedures
- Use representative application performance checks before accepting a smaller post-cutover tier. Quest1 reports comparing API response time, database latency and throughput with JMeter and validating directly queried Views separately; Mydbops recommends utilization baselines, a rollback path and remeasurement after resizing. Applying those checks to long-running secondary reads is an operational inference, not a published tier-sizing formula. (medium confidence) [source]
Problems, failure modes and limitations
- Low CPU alone does not establish that a destination can safely downsize. Atlas blocks automatic compute-tier scale-down when the smaller tier cannot support current disk capacity or provisioned IOPS; Mydbops also warns to check lower-tier connection limits and workload performance before accepting a reduction. (medium confidence) (verified as of 2026-10-14) [source]
- Atlas Core storage auto-scaling only increases storage; storage reduction requires a manual change. Atlas will not automatically downscale the compute tier if the target tier cannot support the current disk capacity or provisioned IOPS, so low CPU utilization alone does not establish eligibility for a smaller tier. (low confidence) (verified as of 2026-10-30) [source]
Comparisons and alternatives
- A destination that is still syncing is not a supported analytics or secondary-read serving cluster: mongosync requires commit and canWrite=true before migrated collections accept application reads or writes. Validate steady-state read performance after that boundary rather than treating pre-cutover reads as a production sizing test. (low confidence) (verified as of 2026-10-14) [source]
- A Nimbly-authored July 1, 2026 incident investigation reports that uncapped reconnect attempts exhausted a node connection ceiling after cluster instability. It concerns maintenance rather than downsizing, so it supports testing reconnect/backoff behavior around infrastructure changes, not a claim that resizing itself caused this outage. (low confidence) [source]
- Mydbops recommends inspecting 30 days of workload metrics before resizing and checking connection limits before downsizing. Treat this duration as practitioner guidance rather than a MongoDB requirement or a guarantee that a lower tier will meet latency objectives. (low confidence) [source]
Facts and statements
- Atlas live-migration guidance says the destination must match or exceed the source in RAM, CPU, and storage and accommodate migration plus the expected workload. It explicitly permits temporarily increasing the destination size and recommends support-assisted performance tuning and sizing after moving the application workload. (high confidence) (verified as of 2026-10-14) [source]
- MongoDB recommends a destination at least two tiers above the source for Atlas pull live migration to accommodate migration-related storage fluctuations. This is guidance for that migration workflow, not a measured universal multiplier for every mongosync topology or steady-state read workload. (medium confidence) (verified as of 2026-10-30) [source]
- The live-migration documentation recommends disabling destination auto-scaling during migration to avoid unexpected sizing changes. This is migration-phase advice; it should not be generalized into a permanent prohibition on production auto-scaling, which Mydbops recommends managing through explicit tier bounds. (medium confidence) (verified as of 2026-10-14) [source]
- An evidence-based post-cutover sizing review should compare representative application latency and throughput alongside resource utilization. This is a synthesis: Mydbops recommends workload-based CPU, memory, and IOPS review, while Quest1 describes reusable JMeter benchmarks comparing application response time, database latency, and throughput across environments and future capacity changes. (medium confidence) [source]
- Pre-provisioning destination capacity is safer than relying on reactive storage scaling for a high-speed bulk load. Atlas warns that storage expansion needs time to prepare and copy data, while its live-migration guidance calls for sufficient destination capacity before migration. (medium confidence) (verified as of 2026-10-14) [source]
Children
- No children recorded.