# 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.)*