Performance Best Practices

A practical checklist for keeping MongoDB queries fast as your data and traffic grow.

Covered Queries

A covered query is one where every field it needs — both the filter and the projection — is present in an index, letting MongoDB answer the query entirely from the index without ever touching the actual documents.

db.users.createIndex({ email: 1, name: 1 });

// Covered — both "email" (filter) and "name" (projection) are in the index
db.users.find({ email: "ada@example.com" }, { name: 1, _id: 0 });

Avoid Unbounded Array Growth

As covered in the schema design lessons, an embedded array that can grow without limit both risks hitting the 16MB document size limit and degrades performance as the document (and any indexes on array fields) grows larger with every write.

Connection Pooling

Opening a new database connection per request is expensive. MongoDB drivers (including the Node.js driver used with Mongoose) maintain a connection pool automatically — reuse a single client instance across your application rather than creating a new one per request.

A Common Serverless Gotcha

In serverless environments (like Vercel functions), creating a new MongoClient on every invocation can exhaust your database's connection limit — cache and reuse a single client instance across invocations where possible.

Read and Write Concerns

Read and write concerns let you tune the tradeoff between consistency/durability and speed, per operation.

Concern	Options	Tradeoff
writeConcern	{ w: 1 } (default) vs { w: "majority" }	w: "majority" waits for more replica confirmation — safer, slightly slower
readConcern	"local" (default) vs "majority"	"majority" guarantees reading only durably committed data, at some latency cost

A Performance Checklist

Index every field your app filters or sorts on frequently, following the ESR rule for compound indexes.
Run explain() on your most important queries and confirm they use IXSCAN, not COLLSCAN.
Avoid unbounded array growth in embedded documents.
Reuse a single database client/connection pool across your application.
Use projection to avoid transferring fields you don't need.

FAQs

What tool should I use to monitor real production performance?

MongoDB Atlas's built-in Performance Advisor, Query Profiler, and real-time metrics dashboard cover most everyday monitoring needs without extra setup.

Is w: "majority" always the right choice?

It's the safer default for most production data, though the very small added latency may not be worth it for less critical, high-volume writes like analytics events.

Summary

Covered queries, bounded document growth, connection reuse, and tuned read/write concerns round out the everyday performance toolkit. With indexing covered, the next section moves into the aggregation framework — MongoDB's tool for complex data transformation and analysis.

Next Lesson →