# MongoDB Capacity Planning > Atlas capacity planning covers four primary resources: RAM (working set), IOPS, storage, and connections. Getting these right prevents both over-provisioning (wasted cost) and under-provisioning (perf Parent: [MongoDB Expert Knowledge](https://llms-explorer.com/tree/mongodb-expert-knowledge/) · 20 facets · 63 facts · page: https://llms-explorer.com/tree/mongodb-capacity-planning/ ## Overview - Atlas capacity planning covers four primary resources: RAM (working set), IOPS, storage, and connections. Getting these right prevents both over-provisioning (wasted cost) and under-provisioning (performance degradation). — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#overview) ## Working Set Sizing (RAM) - The working set is the set of indexes + active document data that MongoDB keeps in WiredTiger cache. When the working set fits in RAM, queries are fast. When it doesn't, cache eviction causes disk I/O spikes. — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#working-set-sizing-ram) - Rule of thumb: Atlas WiredTiger cache = 50% of RAM − 1 GB. An M30 (8 GB RAM) provides ~3 GB of WiredTiger cache. — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#working-set-sizing-ram) ## Estimating Working Set - Working set = frequently accessed document data + all active indexes — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#estimating-working-set) - Indexes must always be hot (in WiredTiger cache). If total index size > cache, performance degrades severely. — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#estimating-working-set) ## Atlas Metrics to Watch - Cache Utilization (%): > 80% signals working set doesn't fit in RAM — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-metrics-to-watch) - Page Faults: > 0 steady-state = working set pressure; growing = critical — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-metrics-to-watch) - WiredTiger Cache Dirty Bytes: Consistently high = eviction pressure — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-metrics-to-watch) ## Atlas IOPS by Tier - GP3 note: All GP3 volumes provide 3000 IOPS baseline regardless of size. For higher IOPS, upgrade to NVMe-backed tiers (M60+) or enable Provisioned IOPS (significant cost increase). — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-iops-by-tier) ## IOPS Forecasting - Write amplification = typically 3-5x for WiredTiger (journaling + checkpoint + compression). — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#iops-forecasting) - Atlas metrics to watch: — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#iops-forecasting) - Disk IOPS Utilization: > 80% = IOPS exhaustion risk — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#iops-forecasting) - Disk Queue Depth: > 1 = IOPS saturation — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#iops-forecasting) ## Storage Forecasting - Add 25% headroom for index growth and temporary operations. — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#storage-forecasting) ## Atlas Autoscaling (Storage) - Atlas can auto-scale storage. Enable in cluster configuration → Autoscaling → Storage. Atlas automatically adds storage when utilization exceeds 90%. Note: storage autoscaling is one-directional (up only). — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-autoscaling-storage) ## Oplog Sizing - Oplog is a capped collection used for replication. Default size: 5% of available disk space (minimum 990 MB, maximum 50 GB). — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#oplog-sizing) - Oplog window = how far back a secondary can fall behind before needing a full resync. — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#oplog-sizing) - Increase oplog if: — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#oplog-sizing) - Secondaries frequently fall behind (replication lag spikes) — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#oplog-sizing) - Maintenance windows require > current oplog window — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#oplog-sizing) - High write rate + slow secondaries — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#oplog-sizing) ## Atlas Connection Limits by Tier - Per-node limits: The above are per-node limits. A 3-node replica set has 3× per-node connections available (reads can go to secondaries). — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-connection-limits-by-tier) ## Connection Pool Sizing - Client applications should use connection pooling. Default pool size in most drivers = 100 connections per MongoClient. — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#connection-pool-sizing) - For serverless/Lambda: set maxPoolSize: 5-10 per function to prevent connection floods. — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#connection-pool-sizing) ## Atlas Autoscaling (Compute) - Enable in cluster configuration → Autoscaling → Compute. — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-autoscaling-compute) - Atlas auto-scales up based on: — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-autoscaling-compute) - Average CPU > 75% over the past hour — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-autoscaling-compute) - Memory utilization > 90% — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-autoscaling-compute) - Atlas auto-scales down based on: — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-autoscaling-compute) - Average CPU < 25% over the past 24 hours — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-autoscaling-compute) - Configure min/max tier bounds to control costs. — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-autoscaling-compute) ## Sharding Triggers - Consider sharding when ALL of the following are true: — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#sharding-triggers) - Single M60+ cluster is consistently maxed on CPU or IOPS — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#sharding-triggers) - Working set won't fit in even the largest single Atlas tier — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#sharding-triggers) - The workload has a natural shard key with good cardinality — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#sharding-triggers) - Do NOT shard prematurely: Sharding adds operational complexity and scatter-gather query overhead. Exhaust vertical scaling options first. — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#sharding-triggers) ## Performance Advisor - Atlas Performance Advisor (M10+ only) automatically analyzes slow queries (> 100ms by default) and recommends indexes. — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#performance-advisor) ## Common Sizing Mistakes - Sizing for peak without autoscaling: Most apps have 5-10x peak-to-baseline ratios; use autoscaling — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#common-sizing-mistakes) - Ignoring index memory: Indexes must be hot; total index size often exceeds "active document" working set estimate — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#common-sizing-mistakes) - Underestimating connection count in serverless environments: Lambda × 100 connections/pool = connection flood — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#common-sizing-mistakes) - Sizing storage on current data only: Model 12-month projected growth + retention policies — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#common-sizing-mistakes) - Choosing M10 for Vector Search in production: mongot and mongod share resources; upgrade to M30+ with dedicated Search Nodes — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#common-sizing-mistakes) - Not setting a connection pool max in containerized apps: Each container starts 100 connections; multiply by container count — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#common-sizing-mistakes) ## References - Atlas Cluster Sizing — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#references) - Atlas Autoscaling — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#references) - Atlas Performance Advisor — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#references) - Atlas Connection Limits — [source](https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#references) ## Where this helps - Sizing a new Atlas cluster before launch, translating expected data volume and query patterns into a RAM/IOPS/storage/connection budget instead of guessing at a tier. — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Diagnosing performance degradation that traces back to cache pressure or IOPS exhaustion rather than a bad query or missing index. — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Deciding when vertical scaling has genuinely been exhausted and sharding is warranted, instead of sharding prematurely for complexity's sake. — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Right-sizing connection pools across serverless functions or containerized deployments to avoid connection floods against per-tier Atlas limits. — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* ## Project ideas - Build a working-set estimator that pulls collection and index sizes via db.stats()/db.collection.stats() and compares them against a target tier's WiredTiger cache budget (50% of RAM minus 1GB). — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Write an autoscaling-policy simulator that models 12-month projected data growth against Atlas storage autoscaling's 90% utilization trigger to catch under-provisioning before it happens. — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Build a connection-count auditor for a serverless deployment that multiplies function concurrency by pool size and flags configurations that would exceed the target tier's per-node connection limit. — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Prototype an oplog-window calculator that estimates how long a secondary can safely fall behind given current write rate and configured oplog size. — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* ## Antipatterns - Sizing a cluster for average load without enabling autoscaling, when most applications see 5-10x peak-to-baseline traffic ratios. — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Estimating working set from active document size alone while ignoring index size — indexes must stay hot in cache too, and total index size often exceeds the document-only estimate. — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Deploying Vector Search on M10 in production, where mongot and mongod share resources on a shared cluster instead of using dedicated Search Nodes. — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Sizing storage only for current data volume instead of modeling 12-month growth plus retention policy, then hitting the one-directional storage-autoscaling ceiling sooner than planned. — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* ## Known issues - Atlas storage autoscaling is one-directional — it adds storage automatically above 90% utilization but never scales storage back down, so a temporary spike leaves a permanently larger and pricier volume. — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - GP3-backed tiers cap at 3000 IOPS baseline regardless of volume size; higher throughput requires upgrading to NVMe-backed tiers (M60+) or paying for Provisioned IOPS. — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - WiredTiger write amplification typically runs 3-5x due to journaling, checkpointing, and compression, so raw application write rate alone will undercount actual disk IOPS demand. — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Performance Advisor's automatic slow-query analysis is only available on M10+ clusters, so smaller shared tiers get no automated index recommendations. — [source](https://llms-explorer.com/tree/mongodb-capacity-planning/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* ## Context files - [MongoDB Capacity Planning](https://llms-explorer.com/downloads/sources/mdb-context-hub/mongodb-capacity-planning.md)