MongoDB Capacity Planning with Practical Examples: A Step-by-Step Implementation Guide

Capacity planning is the discipline of predicting and provisioning the compute, memory, storage, and network resources your MongoDB deployment needs to meet performance and reliability targets with safety margins. Done well, it avoids last-minute emergencies, keeps costs under control, and creates a clear path to scale. This guide gives you a practical, step-by-step approach with constructed examples, verification checks, and recovery playbooks you can apply to standalone servers, replica sets, or sharded clusters.

What you will learn:

• How to inventory versions, topology, and workload basics that matter for sizing.
• How to estimate CPU, memory, storage, and I/O with safety margins.
• How to recognize scaling signals and choose between vertical scaling, replication, and sharding.
• How to verify the results with observable metrics and simple commands.
• How to handle common failure modes and roll back safely.
• A concise checklist to keep operations on track.

Who this is for: developers, DevOps consultants, and technical startup teams designing or evolving MongoDB-backed services, including Node.js and Express APIs.

Assumptions: You have basic familiarity with MongoDB collections and indexes, shell access to database hosts, and the ability to run mongosh and basic OS tools on those hosts.

Version and Environment Inventory

Before you estimate, document what you have. This avoids sizing against guesses and makes comparisons reproducible.

Prerequisites:

• Shell access to database hosts.
• mongosh available.
• Permissions to run read-only diagnostic commands.

Inventory steps (run from a trusted admin host or bastion):

1. Record MongoDB server and shell versions:

   mongosh --eval "db.version()"
   mongod --version

1. Identify topology:

• Replica set:

     mongosh --eval "rs.status().members.map(m => ({name: m.name, stateStr: m.stateStr}))"

• Sharded cluster overview (from mongos):

     mongosh --eval "sh.status()"

1. Collect workload scale markers (constructed example commands):

• Database-level storage stats:

     mongosh --eval "db.stats({scale:1024})"

• Per-collection stats (substitute your collection):

     mongosh --eval "db.getSiblingDB('app').getCollection('orders').stats({scale:1024})"

• Index details for hot collections:

     mongosh --eval "db.getSiblingDB('app').getCollection('orders').stats({indexDetails: true})"

• Server metrics snapshot:

     mongosh --eval "db.serverStatus()"

1. Check replication health (replica sets):

   mongosh --eval "rs.printSlaveReplicationInfo()"

1. Oplog size and headroom (primary):

   mongosh --eval "db.getSiblingDB('local').getCollection('oplog.rs').stats({scale:1024})"

1. OS-level headroom (run on host; constructed examples):

   mpstat 1 5
   nproc
   free -m
   df -h
   iostat -x 1 5

Capture these into a dated record. For repeatability, run the same commands during both typical load and peak windows.

Safe Configuration Path

This section provides a pragmatic path to choose resource targets and scaling tactics with safety margins. All examples are constructed and use hypothetical numbers to illustrate the method.

1. Define Service Targets and Boundaries

• Latency targets: for example, p95 read < 20 ms and p95 write < 30 ms during peak.
• Availability: for example, >= 99.9% monthly.
• Growth horizon: for example, plan for 12 months with 30% uncertainty buffer.

2. Estimate Data Size and Growth (Constructed Worksheet)

Inputs you gather:

• Average document size for hot collections.
• Daily write volume (new docs + updates with growth impact).
• Retention period.
• Index footprint per hot collection.

Simple storage formula (constructed):

• Total data size = sum(hot collection doc bytes + index bytes)
• Monthly growth = daily net growth * 30
• Provisioned capacity = (current size + growth horizon) * safety factor (e.g., 1.3)

Example (hypothetical):

• Orders collection: 5 million docs at 2.5 KB avg -> ~12.5 GB data.
• Indexes on {userId}, {status, createdAt}: combined ~6 GB.
• Other collections net to 8 GB data + 4 GB indexes.
• Current total: ~30.5 GB.
• Daily net growth: 150,000 docs at 2.5 KB -> ~0.36 GB/day data; indexes +0.18 GB/day -> ~0.54 GB/day.
• 12-month growth: ~0.54 * 365 = ~197 GB.
• Provisioned capacity: (30.5 + 197) * 1.3 = ~295 GB.
• Round up to next storage tier with performance headroom.

3. Memory and Working Set

Aim to keep the hot working set in RAM with headroom for background activity and spikes.

Working set approximation (constructed):

• Active docs during peak hour + their indexes.
• If active fraction is 20% of orders and 50% of sessions:
• Orders active: 1 million docs * (2.5 KB + index share 1.2 KB) ~ 3.7 GB.
• Sessions active: 500k docs * (1.0 KB + index 0.6 KB) ~ 0.8 GB.
• Other active: ~1.0 GB.
• Working set ~5.5 GB.

Memory target:

• OS + MongoDB overhead (constructed) ~4-6 GB for utilities and filesystem cache.
• Target RAM = 2x working set + overhead -> ~17 GB; pick 32 GB to keep a strong margin and future growth.

4. CPU and Concurrency

• Track peak ops/sec and typical query complexity.
• Start with a target of sustained CPU < 60% on primaries, < 40% on secondaries used for reads. This keeps headroom for elections, compactions, and bursts.
• If you run CPU-bound aggregations, consider moving them to secondaries (if acceptable) or adding dedicated nodes/shards for such workloads.

5. Disk and I/O

• Choose storage that can deliver the random read/write IOPS and low latency your workload needs.
• Simple I/O budget (constructed):
• Measure peak ops/sec and estimate read/write amplification (e.g., 1-3x per operation, higher with many indexes).
• Ensure provisioned IOPS exceed peak requirement by 30-50%.
• Keep write latency p95 well below your target (for example, < 5 ms device latency for comfortable DB-level p95).

6. Oplog Sizing (Replica Sets)

Size the oplog so it retains at least several hours of peak write traffic, plus safety margin to absorb outages and maintenance windows. For example, if peak sustained insert+update rate is 30 GB/day, ensure oplog is comfortably above the amount generated in your longest failover window (constructed example: 12 hours -> > 15 GB, round up to 32 GB+).

7. Index Strategy Impacts

• Each additional index increases write amplification and memory pressure.
• Favor compound indexes that match your query patterns; avoid overlapping single-field indexes that do not help.
• Periodically validate that indexes are used by sampling query plans.

8. Scaling Choices and Guardrails

• Vertical first: scale CPU/RAM/IOPS until one resource is near 60-70% sustained at peak.
• Replication for availability, read scale, and isolation of reporting workloads.
• Sharding when a single primary cannot keep up with write or data scale; choose a shard key that evenly distributes writes and supports your hottest queries.
• Always test shard key cardinality and monotonicity to avoid hot shards.

9. Safety Margins You Can Communicate

• Capacity target = forecast + uncertainty buffer (commonly 20-50% depending on volatility).
• Alerting thresholds:
• Warn at 60-70% sustained utilization; critical at 80-90% sustained or fast-approaching exhaustion.

Sizing summary table (constructed example):

Verification and Diagnostics

After you size and configure, verify with observable signals. Run checks during both typical and peak windows.

Key checks and commands (constructed examples):

1. Latency and Throughput

• Capture metrics from your application layer and driver (e.g., p50/p95 latencies, ops/sec per route).
• At the database layer, check global operation rates:

  mongosh --eval "db.serverStatus().opcounters"

2. Memory and Cache Health (WiredTiger)

mongosh --eval "db.serverStatus().wiredTiger.cache"

Review:

• bytes currently in the cache vs configured cache size.
• eviction activity: sustained high eviction under steady load suggests cache pressure.

3. Connections and Queues

mongosh --eval "db.serverStatus().connections"

Look for connections nearing configured limits or large spikes.

4. Replication

mongosh --eval "rs.printSlaveReplicationInfo()"

Replication lag should be near zero during steady state and remain within your recovery point objectives during peaks.

5. Index Utilization and Query Shapes

• Sample explain plans:

  mongosh --eval "db.getSiblingDB('app').orders.find({userId: 'U123', createdAt: {$gte: ISODate('2026-01-01')}}).hint({userId:1, createdAt:1}).explain('executionStats')"

• Enable the profiler (short window in a non-peak test) to catch slow operations:

  mongosh --eval "db.setProfilingLevel(1, 50)" # log ops slower than 50 ms
  # ... run workload for 10-15 minutes ...
  mongosh --eval "db.system.profile.find().limit(5).pretty()"
  mongosh --eval "db.setProfilingLevel(0)"

6. Disk and File System

Host level I/O (sample):

iostat -x 1 10

Watch for high await times and saturated utilization during DB peaks.

7. Oplog Consumption

mongosh --eval "db.getSiblingDB('local').oplog.rs.stats({scale:1024})"

Ensure the oplog window (time span covered) exceeds your operational needs.

Scaling signals and indicative actions (constructed):

Expected results if capacity is adequate:

• p95 latencies within target under peak.
• Replication lag near zero with transient spikes that recover quickly.
• Cache eviction not correlated with persistent latency increases.
• Device utilization and await times comfortably below saturation.

If results are not met, adjust one factor at a time and re-verify to isolate the effect.

Failure Modes and Recovery

Capacity shortfalls tend to show up suddenly at peak. Prepare playbooks with simple, reversible actions.

1. Memory Pressure and Cache Churn

Symptoms:

• Spiking cache evictions, increased page reads, rising p95 latencies.

Immediate actions:

• Reduce hot working set: temporarily disable or lower-traffic features that cause wide scans.
• Move reporting or heavy aggregations to secondaries (if acceptable for your consistency needs).
• Increase instance RAM if possible.

Verification:

• Eviction metrics stabilize and latencies drop.

Rollback:

• If you changed cache parameters and saw regressions, restore previous settings and retest.

2. Disk Saturation and Write Stalls

Symptoms:

• High device await times, rising write latencies, replication lag increasing.

Immediate actions:

• Raise storage performance tier or provision additional IOPS.
• Throttle bulk jobs (backfills, re-indexes) to off-peak windows.
• Ensure journaling and filesystem choices are aligned with performance goals.

Verification:

• Device await declines; DB write latencies improve; lag clears.

Rollback:

• If a storage change regresses, revert to previous tier and re-stage migration during maintenance.

3. CPU Saturation and Queue Growth

Symptoms:

• CPU > 80% sustained; slow queries piling up; driver timeouts.

Immediate actions:

• Identify top slow operations; add or adjust indexes for hottest paths.
• Increase vCPU or scale out reads to secondaries.

Verification:

• Reduced queue, lower CPU, improved p95.

Rollback:

• If a new index increases write costs without benefit, drop it.

4. Replication Lag and Failover Risk

Symptoms:

• Seconds to minutes of lag during peaks; secondaries cannot keep up.

Immediate actions:

• Improve secondary I/O and CPU; offload read/reporting; enlarge oplog to buffer peaks.
• Avoid maintenance that further slows secondaries until lag resolves.

Verification:

• Lag remains within target during peak.

Rollback:

• If larger oplog causes storage pressure, reduce after traffic normalizes and you expand disks.

5. Hot Shard or Monotonic Shard Key

Symptoms:

• One shard carries disproportionate load; chunk migrations thrash.

Immediate actions:

• Add balancing windows; consider resharding with a higher-cardinality or hashed key.

Verification:

• Load distribution evens out; balancing stabilizes.

Rollback:

• If a reshard plan degrades queries, revert to previous key only after a tested migration plan; otherwise, adjust indexes on the new key.

6. Disk Full Scenarios

Symptoms:

• Writes fail; replication stalls; logs show out-of-space errors.

Immediate actions:

• Free space (delete temp files, old logs), expand volume, or move data path to a larger volume.
• Temporarily reduce write traffic if possible.

Verification:

• Writes resume; no journal or checkpoint errors.

Rollback:

• If moving data paths causes issues, roll back to the known-good mount with sufficient space during maintenance.

Recovery checks after any change:

• p95 latencies back within targets for sustained periods.
• No error-rate increase at the app or driver level.
• Replication healthy and elections not flapping.
• Backups still complete within their windows.

Operations Checklist

Use this checklist to keep capacity aligned with growth. Tailor intervals to your change rate.

Weekly

• Review p95 latencies, throughput, and error rates from the app layer.
• Spot-check explain plans for top queries.
• Verify replication lag remains within target during peaks.

Monthly

• Refresh data and index size stats for hot collections.
• Compare observed growth vs forecast; update the next 3-6 month outlook.
• Validate working set assumptions against cache metrics.
• Confirm storage free space > 30% and IOPS headroom > 30% under peak.
• Audit index set for redundancy; drop unused indexes after verification.

Quarterly

• Load-test a narrow, measurable pilot scenario representative of peak (constructed test):
• Choose 1-2 hottest endpoints.
• Replay realistic traffic volume with captured query shapes.
• Validate latency and error targets, then adjust capacity plans.
• Reassess shard key suitability if growth is skewed.
• Dry-run recovery and backup restores.

Change Management

• Apply one change at a time and measure.
• Keep a rollback plan for configuration, index, and topology changes.
• Document decisions, thresholds, and outcomes for future reviews.

Example capacity review table (constructed):

Conclusion

Capacity planning for MongoDB is not a one-time guess; it is an iterative practice that turns observed workload behavior into resourced, testable plans with safety margins. Start with a clear inventory, size storage and memory around the working set, keep CPU and I/O within comfortable headroom, and choose the simplest scaling step that preserves your targets. Verify with concrete metrics and simple commands, and be ready with recovery playbooks for the common failure modes you will encounter at scale. By revisiting these steps on a regular cadence and piloting changes in narrow, measurable scenarios first, you will reduce rework, keep risk low, and maintain predictable performance as your data and traffic grow.