MongoDB Capacity Planning

Parent: MongoDB Expert Knowledge · researched 2026-05-28T15:41:33.084Z· 6 sources · 12 concepts · skill 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

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]

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]
Rule of thumb: Atlas WiredTiger cache = 50% of RAM − 1 GB. An M30 (8 GB RAM) provides ~3 GB of WiredTiger cache. [source]

Estimating Working Set

Working set = frequently accessed document data + all active indexes [source]
Indexes must always be hot (in WiredTiger cache). If total index size > cache, performance degrades severely. [source]

Atlas Metrics to Watch

Cache Utilization (%): > 80% signals working set doesn't fit in RAM [source]
Page Faults: > 0 steady-state = working set pressure; growing = critical [source]
WiredTiger Cache Dirty Bytes: Consistently high = eviction pressure [source]

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]

IOPS Forecasting

Write amplification = typically 3-5x for WiredTiger (journaling + checkpoint + compression). [source]
Atlas metrics to watch: [source]
Disk IOPS Utilization: > 80% = IOPS exhaustion risk [source]
Disk Queue Depth: > 1 = IOPS saturation [source]

Storage Forecasting

Add 25% headroom for index growth and temporary operations. [source]

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]

Oplog Sizing

Oplog is a capped collection used for replication. Default size: 5% of available disk space (minimum 990 MB, maximum 50 GB). [source]
Oplog window = how far back a secondary can fall behind before needing a full resync. [source]
Increase oplog if: [source]
Secondaries frequently fall behind (replication lag spikes) [source]
Maintenance windows require > current oplog window [source]
High write rate + slow secondaries [source]

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]

Connection Pool Sizing

Client applications should use connection pooling. Default pool size in most drivers = 100 connections per MongoClient. [source]
For serverless/Lambda: set maxPoolSize: 5-10 per function to prevent connection floods. [source]

Atlas Autoscaling (Compute)

Enable in cluster configuration → Autoscaling → Compute. [source]
Atlas auto-scales up based on: [source]
Average CPU > 75% over the past hour [source]
Memory utilization > 90% [source]
Atlas auto-scales down based on: [source]
Average CPU < 25% over the past 24 hours [source]
Configure min/max tier bounds to control costs. [source]

Sharding Triggers

Consider sharding when ALL of the following are true: [source]
Single M60+ cluster is consistently maxed on CPU or IOPS [source]
Working set won't fit in even the largest single Atlas tier [source]
The workload has a natural shard key with good cardinality [source]
Do NOT shard prematurely: Sharding adds operational complexity and scatter-gather query overhead. Exhaust vertical scaling options first. [source]

Performance Advisor

Atlas Performance Advisor (M10+ only) automatically analyzes slow queries (> 100ms by default) and recommends indexes. [source]

Common Sizing Mistakes

Sizing for peak without autoscaling: Most apps have 5-10x peak-to-baseline ratios; use autoscaling [source]
Ignoring index memory: Indexes must be hot; total index size often exceeds "active document" working set estimate [source]
Underestimating connection count in serverless environments: Lambda × 100 connections/pool = connection flood [source]
Sizing storage on current data only: Model 12-month projected growth + retention policies [source]
Choosing M10 for Vector Search in production: mongot and mongod share resources; upgrade to M30+ with dedicated Search Nodes [source]
Not setting a connection pool max in containerized apps: Each container starts 100 connections; multiply by container count [source]

References

Atlas Cluster Sizing [source]
Atlas Autoscaling [source]
Atlas Performance Advisor [source]
Atlas Connection Limits [source]

Children

Working Set Sizing (frontier)
IOPS Forecasting (frontier)
Storage Growth Modeling (frontier)
Connection Capacity (frontier)
Oplog Sizing (frontier)
Cluster Tier Selection (frontier)
Sharding Triggers (frontier)
Read vs Write Distribution (frontier)
Atlas Performance Advisor (frontier)
Growth Signals (frontier)
Capacity Testing (frontier)
Common Sizing Mistakes (frontier)

Frontier under this node: Capacity Testing, Cluster Tier Selection, Common Sizing Mistakes, Connection Capacity, Growth Signals, IOPS Forecasting, Oplog Sizing, Read vs Write Distribution, Sharding Triggers, Storage Growth Modeling, Working Set Sizing

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