Benchmark: Query Performance with Mongoose 7.x on Sharded Clusters

Benchmarks help teams make informed decisions. We ran a series of controlled experiments to measure how Mongoose 7.x performs against sharded MongoDB clusters under realistic workloads. This post documents the setup, results, and practical takeaways.

Benchmark objectives

We focused on three objectives:

1. Measure raw read and write latency with varying concurrency.
2. Evaluate the impact of index coverage on aggregation queries.
3. Observe client-side behavior under shard rebalances and chunk migrations.

Test environment

Cluster:

• 3 mongos routers, 6 shards (replica sets), wired with 10Gb network
• Data set: 120 million documents, ~300GB total

Client:

• Node.js 20-based runner using Mongoose 7.3
• 10 containers simulating application services; each process configured with poolSize=50

Workloads

We used three representative workloads:

• Point reads: Targeted by shard key, returning small documents.
• Range queries: Non-shard-key ranges requiring query routing to multiple shards.
• Aggregation-heavy: Pipelines with $lookup and multiple stages simulating reporting endpoints.

Key results

Highlights:

• Point reads: Achieved median latency of 8–12ms at 10k RPS across the cluster with p99 below 40ms when queries included the shard key and used covered indexes.
• Range queries: Range queries without shard key saw p50 latency increase by 3–5x and p99 spikes during chunk migrations, underscoring the need for targeted queries.
• Aggregations: Complex pipelines that required cross-shard $lookup were the slowest; precomputing denormalized views or using dedicated reporting clusters improved stability.

Observations about Mongoose

Mongoose itself accounted for very little of the latency in these tests when using .lean() for reads. However, certain patterns impacted performance:

• Large document hydration: Converting thousands of documents into full Mongoose model instances increased memory and GC pressure — avoid hydrations when not needed.
• Middleware overhead: Heavy synchronous middleware in write paths impacted throughput dramatically. Asynchronous, batched processing kept latency stable.
• Connection pooling: Improper pool sizing at application scale caused queuing and increased tail latency; tuning per-container pools matched to instance vCPUs was essential.

Shard migration effects

Chunk migrations are a reality in sharded clusters. Our tests found:

• Background chunk migrations increased I/O and could temporarily raise p99 latency for affected queries.
• Using a smooth rebalancer policy and scheduling maintenance during low traffic mitigated impacts.

Recommendations

• Design queries to include the shard key for latency-critical endpoints.
• Build covered indexes for frequently used projections and sorts.
• Use .lean() to avoid unnecessary document instantiation for read-heavy workloads.
• Offload heavy aggregations to background workers or reporting clusters.
• Tune connection pools per host, and consider a connection proxy for serverless environments.

Conclusion

Mongoose 7.x performs reliably on sharded clusters when best practices are followed: targeted queries, index coverage, and careful middleware design. The biggest improvements come from modeling and index strategy rather than from micro-optimizing the ODM itself.

If you'd like the full benchmark suite and raw metrics, we're sharing the scripts and dashboards in our public repo so teams can reproduce and extend our tests for their own workloads.