MongoDB Capacity Planning

Parent: MongoDB Expert Knowledge · Published reference · snapshot 2026-09-08 · skill atlas-diagnostics-expert/references/mongodb-capacity-planning.md

↓ Facts as markdown all context files

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

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.

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). [archived 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. [archived 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. [archived 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 [archived 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. [archived 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 [archived 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 [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-metrics-to-watch]
WiredTiger Cache Dirty Bytes: Consistently high = eviction pressure [archived 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). [archived 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). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#iops-forecasting]
Atlas metrics to watch: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#iops-forecasting]
- Disk IOPS Utilization: > 80% = IOPS exhaustion risk [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#iops-forecasting]
- Disk Queue Depth: > 1 = IOPS saturation [archived 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. [archived 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). [archived 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). [archived 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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#oplog-sizing]
Increase oplog if: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#oplog-sizing]
- Secondaries frequently fall behind (replication lag spikes) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#oplog-sizing]
- Maintenance windows require > current oplog window [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#oplog-sizing]
- High write rate + slow secondaries [archived 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). [archived 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. [archived 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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#connection-pool-sizing]

Atlas Autoscaling (Compute)

Enable in cluster configuration → Autoscaling → Compute. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-autoscaling-compute]
Atlas auto-scales up based on: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-autoscaling-compute]
- Average CPU > 75% over the past hour [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-autoscaling-compute]
- Memory utilization > 90% [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-autoscaling-compute]
Atlas auto-scales down based on: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-autoscaling-compute]
- Average CPU < 25% over the past 24 hours [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#atlas-autoscaling-compute]
Configure min/max tier bounds to control costs. [archived 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: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#sharding-triggers]
- Single M60+ cluster is consistently maxed on CPU or IOPS [archived 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 [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#sharding-triggers]
- The workload has a natural shard key with good cardinality [archived 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. [archived 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. [archived 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 [archived 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 [archived 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 [archived 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 [archived 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 [archived 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 [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#common-sizing-mistakes]

References

Atlas Cluster Sizing [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#references]
Atlas Autoscaling [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#references]
Atlas Performance Advisor [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-capacity-planning/#references]
Atlas Connection Limits [archived 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] — 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] — 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] — 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] — 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] — 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] — 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] — 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] — 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] — 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] — 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] — 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] — 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] — 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] — 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] — 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] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Children

Working Set Sizing (frontier, viability 4.25 / 5)
Connection Capacity (frontier, viability 4.38 / 5)
Oplog Sizing (frontier, viability 4.28 / 5)
Sharding Triggers (frontier, viability 3.48 / 5)
Read vs Write Distribution (frontier, viability 3.83 / 5)
Growth Signals (frontier, viability 3.25 / 5)
Capacity Testing (frontier, viability 3.25 / 5)
Common Sizing Mistakes (frontier, viability 3.02 / 5, below research gate)

Frontier under this node: Atlas Performance Advisor, Capacity Testing (3.25), Cluster Tier Selection, Common Sizing Mistakes (3.02), Connection Capacity (4.38), Growth Signals (3.25), IOPS Forecasting, Oplog Sizing (4.28), Read vs Write Distribution (3.83), Sharding Triggers (3.48), Storage Growth Modeling, Working Set Sizing (4.25)

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