# Right-sizing from Atlas metrics > Source-anchored research for Right-sizing from Atlas metrics. Run status: COMPLETED. Parent: [Atlas Cost Planning: Region Pricing, Estimation, Scheduled Scaling and Competitor TCO](https://llms-explorer.com/tree/atlas-cost-planning-region-pricing-estimation-scheduled-scaling-and-competitor-tco/) · 5 facets · 12 facts · page: https://llms-explorer.com/tree/right-sizing-from-atlas-metrics/ ## Structure and components - Efficient query and index design can reduce memory demand and help avoid a higher instance tier; resource demand should be reviewed after tuning as part of the sizing decision. (medium confidence) — [source](https://community.ibm.com/community/user/blogs/manish-negandhi/2026/04/14/optimizing-mongodb-atlas-cost) ## How-to and procedures - Use several resource dimensions to assess a smaller Atlas tier: CPU, memory and WiredTiger cache, disk IOPS, connections, and workload latency. Low CPU alone does not establish that the smaller tier will satisfy the workload. (high confidence) — [source](https://www.mongodb.com/docs/atlas/architecture/current/cost-saving-config/) ## Measurements and reference values - MongoDB recommends reviewing CPU, WiredTiger cache, memory and IOPS over a rolling 30-day period of normal use; its cost guide flags consistently low System Max: User CPU utilization under 45% as a downsizing signal. These are review heuristics, not sufficient conditions for automatic scale-down. (low confidence) (verified as of 2026-10-24) — [source](https://www.mongodb.com/docs/atlas/architecture/current/cost-saving-config/) - Atlas Core operational-node scale-down currently requires CPU below 45%, WiredTiger cache usage below 90% of its maximum, and projected target-tier memory utilization below 60%, each over both the last 10 minutes and four hours. Other timing and cluster conditions also apply; a single quiet sample is insufficient. (low confidence) (verified as of 2026-10-24) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core/) ## Problems, failure modes and limitations - MongoDB process resident memory excludes other processes on the node. Atlas system memory and the projected memory used for scale-down represent different quantities, so the resident-memory chart cannot substitute for the target-tier memory calculation. (high confidence) — [source](https://www.mongodb.com/docs/atlas/review-available-metrics/) - Atlas CPU interpretation has an additional caveat for burstable M10/M20 tiers: scaling decisions use CPU relative to the provider baseline. With a 20% baseline, 75% relative CPU corresponds to 15% normalized CPU, so apparently low normalized CPU need not indicate spare baseline capacity. (low confidence) (verified as of 2026-10-24) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core/) ## Comparisons and alternatives - OneUptime proposes collecting at least two weeks of baseline metrics, including weekday and weekend patterns, and watching metrics for 48 hours after a tier change. These durations are the blog author's checklist rather than an Atlas service guarantee. (low confidence) (verified as of 2026-03-31) — [source](https://oneuptime.com/blog/post/2026-03-31-mongodb-right-size-atlas-clusters/view) - Normalized System CPU covers all processes on a node and divides CPU usage by the number of cores to produce a 0–100% scale. It differs from MongoDB process CPU, so sizing comparisons must retain the metric identity. (high confidence) — [source](https://www.mongodb.com/docs/atlas/review-available-metrics/) - Atlas computes projected target-tier memory as current memory used minus current WiredTiger cache usage plus 80% of the smaller tier's maximum WiredTiger cache, divided by the smaller tier's RAM. This explicitly tests memory demand against the proposed destination rather than only the current tier. (low confidence) (verified as of 2026-10-24) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core/) - Cache fill measures occupied cache bytes divided by configured cache bytes; it is not a cache-hit percentage. Review cache reads from disk, disk IOPS versus provisioned limits, and disk latency alongside cache occupancy when judging memory pressure. (high confidence) — [source](https://www.mongodb.com/docs/atlas/review-available-metrics/) - A July 28, 2026 MongoDB feedback submission reports that dirty-cache pressure, eviction stalls and ticket exhaustion can degrade latency while CPU and memory remain below scaling thresholds. Treat this as a reported failure mode rather than evidence that every such workload fails or that the request remains unimplemented. (low confidence) (verified as of 2026-07-28) — [source](https://feedback.mongodb.com/ideas/CUSTOMER-I-10648) - Sumo Logic's Atlas collector sample enables cache dirty/used bytes, connections, resident memory, operation execution times, normalized system CPU, and disk IOPS/latency metrics. This supplies a concrete external metrics-collection example for sizing reviews, rather than a built-in right-sizing algorithm. (low confidence) (verified as of 2026-10-24) — [source](https://github.com/SumoLogic/sumologic-mongodb-atlas/blob/master/mongodbatlas_sample.yaml)