MongoDB Performance — Explain Plans, Covered Queries & Pagination

A covered query is answered entirely from the index — MongoDB never has to fetch the actual document from the collection at all, because every field the query needs (both the filter and the returned projection) already lives inside the index itself.

db.customers.createIndex({ name: 1 });

// NOT covered — projection includes fields not in the index (and _id is
// included by default, and _id is not part of this index either)
db.customers.find({ name: "Max" }).explain("executionStats");
// totalDocsExamined: 1  — still had to fetch the actual document

// covered — filter field AND every projected field are in the index,
// and _id is explicitly excluded
db.customers.find({ name: "Max" }, { _id: 0, name: 1 }).explain("executionStats");
// totalDocsExamined: 0  — answered entirely from the index

Two conditions have to hold together: every field in the query's filter must be in the index, and every field in the projection must be in the index too — including _id, which MongoDB includes by default unless you explicitly write _id: 0.

This is the identical lesson SQL Mastery, Chapter 02 teaches about OFFSET in SQL — the mechanism is different (a B-tree walk vs. an index walk) but the root cause is the same: an offset-based cursor has no way to seek directly into the middle of an ordered result set, in either database, so it pays for every row or document it skips past, every single request.

Instead of "skip N," keyset pagination asks a question the index can answer in constant time: "give me the next 20 after this specific point I already saw." The cursor is the last-seen document's sort-key value, not a row count — so the index seeks directly to it, no matter how many pages deep you already are.

// Page 1 — no cursor yet
db.products.find().sort({ _id: -1 }).limit(20);

// Page 2+ — pass the LAST _id seen on the previous page as lastSeenId
db.products.find({ _id: { $lt: lastSeenId } }).sort({ _id: -1 }).limit(20);
// the index SEEKS directly to lastSeenId, then reads 20 forward from there —
// constant-time work regardless of how many pages deep you are

Because MongoDB's default _id (ObjectId) is roughly time-ordered (Chapter 02 §4), it's often directly usable as a natural keyset cursor for a createdAt-style feed with no extra field needed. Sorting on a non-unique field (like price) needs a compound tie-breaker so two documents with the same price don't get skipped or duplicated across pages — the same technique SQL keyset pagination uses:

db.products.find({
  $or: [
    { price: { $gt: lastPrice } },
    { price: lastPrice, _id: { $gt: lastId } }
  ]
}).sort({ price: 1, _id: 1 }).limit(20);

Keyset pagination trades away one real capability: it only supports "next page" and "previous page" relative to a cursor, not "jump to page 47." If a product genuinely needs arbitrary page-number jumping at real depth, that's a harder problem (usually solved by capping how deep users can actually jump, or paginating a pre-computed, cached result set) rather than something either pagination style solves cleanly on its own. Verify any pagination fix the same way Chapter 02 taught — with explain("executionStats") on the actual query at a realistic page depth, not just on page 1.