Slow query shapes
High examined-to-returned ratios, collection scans, blocking sorts, inefficient lookups, or plans that regress as data changes.
Query and system diagnostics
MongoDB performance tuning from measured evidence
In short: MongoDB performance tuning finds the constraint with profiler samples, explain plans, index statistics, aggregation evidence, WiredTiger metrics, and system telemetry. Each change is tested against a baseline and reviewed for write, storage, and operational trade-offs.
The target is a reproducible improvement on your workload—not a generic cache percentage, index count, or performance multiplier.
Diagnostic signals
Symptoms are clues, not root causes
Similar latency can come from a plan regression, cache churn, storage, replication, routing, or application behavior. We preserve that distinction during diagnosis.
Aggregation bottlenecks
Expensive stage ordering, memory pressure, excessive document fan-out, or pipelines that cannot use selective indexes early.
Working-set pressure
WiredTiger eviction pressure, cache churn, filesystem I/O, checkpoint stress, or memory limits that do not match the runtime environment.
Distributed-query overhead
Scatter-gather queries, uneven shard traffic, migration pressure, replication lag, or a routing pattern that amplifies latency.
Method
A tuning loop your team can reproduce
- 01
Capture a safe baseline
Define affected operations and record representative latency percentiles, throughput, resource use, query plans, and data volume before changes.
- 02
Find the constraint
Correlate profiler samples, explain execution statistics, index use, WiredTiger counters, I/O, replication, and shard behavior.
- 03
Change one layer at a time
Test query, index, pipeline, schema, or configuration changes in a representative environment with explicit rollback conditions.
- 04
Validate and document
Compare the same workload against the baseline, check write and storage trade-offs, document the result, and define regression alerts.
Tuning scope
Every recommendation names its evidence
Query-plan analysis
Inspect winning and rejected plans, execution statistics, selectivity, sort behavior, plan-cache effects, and documents or keys examined.
Evidence: explain("executionStats"), profiler samples, query-shape frequency
Index design
Evaluate compound key order, equality-sort-range patterns, covered queries, partial indexes, multikey behavior, write cost, and unused indexes.
Evidence: $indexStats, query coverage, cardinality, write amplification
Aggregation pipelines
Move selective stages earlier where semantics permit, reduce intermediate documents, inspect lookup strategy, and validate memory or spill behavior.
Evidence: Pipeline explain output, stage cardinality, memory and spill signals
WiredTiger and memory
Measure cache occupancy, eviction, dirty bytes, checkpoints, filesystem I/O, and container limits before considering an explicit cache override.
Evidence: serverStatus().wiredTiger, hostInfo, OS and container metrics
Shard and replica behavior
Separate routing, distribution, migration, replication, and network effects from local query execution before recommending topology work.
Evidence: Targeted-shard plans, chunk distribution, lag and network metrics
Guardrails and monitoring
Add workload-specific dashboards and alerts for latency, scans, cache pressure, queueing, replication, and known regression signatures.
Evidence: Acceptance thresholds, rollback triggers, post-change observation window
WiredTiger cache
Do not copy a memory percentage from a checklist
MongoDB documents the default WiredTiger internal cache as the larger of 50% of (RAM minus 1 GB) or 0.256 GB, and advises against increasing it above the default without a specific reason. That cache is only one memory consumer.
Filesystem cache, connections, aggregations, index builds, other processes, multiple mongod instances, and container limits all affect a safe value. We inspect hostInfo, WiredTiger eviction and dirty-cache signals, OS metrics, and the runtime memory boundary before proposing an override.
Primary references
Visible sources for the tuning method
Product behavior is checked against current MongoDB documentation. Recommendations still depend on your version, workload, deployment model, and observed evidence.
FAQ
MongoDB performance tuning questions
What is MongoDB performance tuning?
MongoDB performance tuning is the process of measuring a slow or resource-intensive workload, identifying the limiting layer, testing a targeted change, and validating the same workload afterward. Common layers include query shapes, indexes, aggregation pipelines, document design, WiredTiger behavior, replication, sharding, storage, and host or container resources.
What usually makes a MongoDB aggregation pipeline slow?
Common causes include insufficiently selective early stages, missing or unsuitable indexes, large intermediate result sets, fan-out from $unwind or $lookup, blocking sorts or groups, document growth, and cross-shard work. The correct fix comes from pipeline explain output and representative data; reordering stages without checking semantics can change results.
Should wiredTigerCacheSizeGB be set to 50–60% of RAM?
Not as a blanket rule. MongoDB's documented default internal cache is the larger of 50% of (RAM minus 1 GB) or 0.256 GB, and MongoDB advises against increasing it above the default without a specific reason. The operating system, filesystem cache, connections, aggregations, index builds, multiple mongod processes, and container memory limits also need RAM. We measure those consumers and WiredTiger eviction behavior before setting an override.
Do you tune MMAPv1 deployments?
MMAPv1 is a removed legacy storage engine, not a current MongoDB tuning option. Current self-managed MongoDB and Atlas use WiredTiger. A legacy deployment that still depends on MMAPv1 needs migration and upgrade planning before modern performance work.
How do you prove that a tuning change helped?
We compare the same representative operation and data conditions before and after the change. Validation can include latency percentiles, throughput, documents and keys examined, CPU, I/O, cache and eviction metrics, replication lag, and write or storage cost. Results are workload-specific, so we do not promise a fixed multiplier before measurement.
Which MongoDB versions do you support?
We inventory the server release, patch level, feature compatibility version, drivers, deployment model, and tooling, then check them against MongoDB's current versioning documentation. End-of-life or incompatible deployments receive an upgrade recommendation before tuning changes that depend on newer behavior.
Can you tune MongoDB Atlas?
Yes. Query plans, indexes, profiler evidence, Performance Advisor suggestions, aggregation behavior, and cluster metrics can all inform an Atlas tuning engagement. Atlas tier, autoscaling, networking, search, and platform-governance decisions are scoped separately when they extend beyond the measured database bottleneck.
Technical review and primary sources
MongoDB performance guidance and measurement sources
Review scope: Query plans, index design, WiredTiger cache behavior, working-set analysis, and workload-specific validation. Guidance is checked against primary documentation; deployment targets and performance outcomes remain workload- and contract-specific.
Review owner: JusDB Database Reliability Engineering team. Last reviewed: .
- Explain results
Execution-plan fields used for query diagnosis.
- MongoDB index strategies
Index design and query-coverage guidance.
- WiredTiger storage engine
Cache defaults, compression, and filesystem-cache considerations.
Related MongoDB Services
Explore more ways our MongoDB consultants can help optimize your database infrastructure
MongoDB Consulting
Architecture assessments, schema and shard-key decisions, and implementation roadmaps
MongoDB Support
Plan-based incident response, troubleshooting, escalation, and lifecycle guidance
MongoDB High Availability
Replica-set and sharded-cluster resilience with tested, topology-specific recovery targets
Explore all MongoDB services
Need a different MongoDB service? Browse our complete offerings.