MongoDB Cheat Sheet

Documents are BSON (typed JSON). `_id` is required. One document write is atomic.

• vs SQLdocument-oriented, not tables and rows
• BSONObjectId, Date, Decimal128, ints — JSON cannot hold these
• _idimmutable unique key; usually an ObjectId

`$in` on one field beats `$or` of equalities. `$or` across different fields needs an index per branch.

db.users.find(
  { city: "Bangalore" },
  { name: 1, email: 1 }
)

• 1include the field
• 0exclude the field
• _idreturned unless you set `_id: 0`

Do not mix include and exclude, except excluding `_id` on an include list. Projection can make a query covered.

{ "address.city": "Bangalore" }

{ skills: "Node.js" }

{ skills: { $all: ["Node.js", "MongoDB"] } }

{
  skills: {
    $elemMatch: {
      name: "Node.js",
      experience: { $gt: 2 }
    }
  }
}

Dot notation on arrays of objects can match different elements. Use `$elemMatch` when one element must satisfy every condition.

db.orders.find({ status: "completed" })
  .sort({ createdAt: -1 })
  .limit(10)
  .skip(20)

• 1 / -1ascending / descending
• Small datasetskip/limit can be fine
• Large datasetprefer cursor-based pagination

db.orders.find({ _id: { $gt: lastId } })
  .sort({ _id: 1 })
  .limit(10)

`skip(n)` still walks n documents. Cost grows with page number. Interview takeaway: offset pagination does not scale.

db.orders.aggregate([
  { $match: { status: "completed" } },
  {
    $group: {
      _id: "$userId",
      totalSpent: { $sum: "$amount" }
    }
  },
  { $sort: { totalSpent: -1 } },
  { $limit: 3 }
])

`$match` early. `$lookup` is a left outer join — index the foreign field, and do not use it as a default for every relationship.

• Embeddingfewer queries · data can duplicate · document can grow
• Referencingnormalized · extra queries / `$lookup` · independent documents

Start from the access pattern. Order `items` embed. A user's orders reference. Documents cap at 16MB.

db.users.createIndex({ email: 1 })

db.orders.createIndex({ userId: 1, createdAt: -1 })

db.users.createIndex({ email: 1 }, { unique: true })

db.sessions.createIndex(
  { createdAt: 1 },
  { expireAfterSeconds: 3600 }
)

• Readsindexes speed them up
• Coststorage + write overhead
• ESREquality → Sort → Range
• Prefix{a,b,c} serves a, a+b, a+b+c — not b alone

db.orders.find({ status: "delivered" }).explain("executionStats")

• COLLSCANcollection scan
• IXSCANindex scan

Prefer IXSCAN for selective queries. COLLSCAN is not automatically wrong — a tiny collection or a query that must read most documents can still scan. Judge the plan against the query and the dataset. Look at examined vs returned.

• One documentalready atomic
• Several documentstransaction may be required

session.startTransaction()
// operations
await session.commitTransaction()

await session.abortTransaction()

Transactions give atomicity across multiple operations. Use them when necessary — not as the default write path. Prefer a model where one document write is enough.

• Atomic updatesafest when one document is enough
• Transactioncoordinate multiple operations
• Raceconcurrent ops produce incorrect state

// race
const product = await products.findOne({ _id })
await products.updateOne(
  { _id },
  { $set: { stock: product.stock - 1 } }
)

// atomic
await products.updateOne(
  { _id, stock: { $gt: 0 } },
  { $inc: { stock: -1 } }
)

const client = new MongoClient(MONGO_URI);

await client.connect();

const db = client.db("app");
const users = db.collection("users");

const user = await users.findOne({ email });

Do not create a new MongoDB connection for every request. Reuse the MongoClient / connection pool.

• Schemastructure + validation
• Modelinterface for a collection
• Documentone MongoDB document

• Replica sethigh availability, failover, replication
• Shardinghorizontal scaling — data across shards
• Read preferencewhere reads are allowed to go
• Write concernhow much acknowledgement a write needs
• Read concernhow consistent a read must be

• ✕No indexes on frequently queried fields

  →Index the equality and sort fields your hot queries actually use. Learn

• ✕Too many indexes

  →Every index costs writes and RAM. Drop unused ones. Learn

• ✕Using skip() for massive pagination

  →Use a cursor on `_id` or a unique sorted field. Learn

• ✕Unbounded arrays

  →Reference or bucket once the array can grow without a cap. Learn

• ✕Returning huge documents

  →Project the fields the caller needs. Learn

• ✕Overusing $lookup

  →Embed data that is always read together; lookup is not a default join. Learn

• ✕Treating flexible schema as “no schema”

  →The schema still lives somewhere — usually in application code or validators. Learn

• ✕Creating a new DB connection per request

  →Reuse one MongoClient and its pool. Learn

• ✕Using transactions unnecessarily

  →Model so a single-document write is the common case. Learn

• ✕Passing a string instead of ObjectId

  →Cast with `new ObjectId(id)` (or let Mongoose do it). Learn

• ✕Not checking explain()

  →Read executionStats before guessing an index. Learn

• MongoDB vs SQL

  MongoDB is document-oriented with a flexible document model. SQL is relational with a structured schema.

• Embedding vs referencing

  Embed when data belongs together and is bounded. Reference when it is independent, large, or unbounded.

• Index

  Faster reads, paid for with storage and write overhead.

• Aggregation

  A pipeline of stages that transforms documents.

• Transactions

  Useful when multiple operations must succeed or fail together.

• Replica set

  High availability and failover.

• Sharding

  Horizontal scaling by distributing data across shards.

• $elemMatch

  All conditions must hold on the same array element.

• ESR

  Equality fields, then sort, then range.