Why Your MongoDB Queries Are Slow
Nine times out of ten, a slow MongoDB query is a missing index. Without an index, MongoDB has to scan every document in the collection to find matches — fine with a thousand documents, a disaster with a million. Indexing is the highest-leverage performance work you can do on a database, and it is more approachable than most developers assume.
How an Index Actually Works
An index is a sorted data structure that maps values to the documents containing them — like the index at the back of a book. Instead of reading every page to find a topic, you jump straight to it. The trade-off is that indexes take up space and add a small cost to writes, because every insert or update must also update the indexes. So you index deliberately, not on every field.
Single-Field vs Compound Indexes
A single-field index covers queries that filter on one field. A compound index covers queries that filter on several fields together — and here order matters enormously. A compound index on { status, createdAt } efficiently serves queries filtering by status, or by status and createdAt, but not queries filtering by createdAt alone. Think of it as sorting by the first field, then the second within that. Design the index to match how you actually query.
The ESR Rule for Compound Indexes
A reliable rule for ordering fields in a compound index is Equality, Sort, Range. Put fields you match exactly first, then fields you sort by, then fields you query as a range (greater-than, less-than). Following ESR turns many slow queries fast without any other change.
Covered Queries: The Fast Path
If an index contains every field a query needs — both for filtering and for the fields it returns — MongoDB can answer the query from the index alone without touching the documents. This is a covered query, and it is about as fast as MongoDB gets. When a query is hot and performance-critical, designing an index to cover it entirely is worth the effort.
Find Slow Queries with explain()
You do not have to guess. Run a query with .explain("executionStats") and read the output:
- COLLSCAN means a full collection scan — a missing index, and your prime suspect.
- IXSCAN means an index is being used — good.
- Compare documents examined to documents returned — if MongoDB examined 100,000 docs to return 10, your index is not selective enough.
This single tool turns indexing from guesswork into measurement.
Common Mistakes
- Indexing everything — every index slows writes and eats memory. Index for your real query patterns, not hypothetically.
- Wrong field order — a compound index in the wrong order may not be used at all.
- Ignoring memory — indexes work best when they fit in RAM; bloated, unused indexes waste it.
How Dharmsy Optimizes Databases
We profile real query patterns with explain(), design indexes around how the app actually reads data, and remove the unused indexes that quietly slow writes. If your MongoDB-backed app has slow pages or timeouts, an indexing review is usually the fastest win available.