162 MongoDB Interview Questions and Answers (2026)

A namespace in MongoDB is the fully qualified name that uniquely identifies a collection or index, formed by joining the database name and collection name with a dot.

• Format:

  • Written as database.collection, e.g. shop.orders.

  • Indexes also have namespaces, internally combining collection and index name.

• Purpose:

  • Lets the storage engine and system catalog uniquely address every data container.

  • Used in logs, profiler output, and errors to point at the exact collection.

• Constraints:

  • Length limit is 255 bytes for a namespace under WiredTiger.

  • Avoid $ and null characters in names.

Every document must have a unique _id field that acts as its primary key; if you don't supply one, MongoDB auto-generates an ObjectId, a 12-byte value that is unique and roughly time-ordered.

• The _id field:

  • Mandatory and unique per collection; automatically indexed with a unique index that cannot be dropped.

  • Can be any type (integer, string, UUID), not just an ObjectId, but it is immutable once set.

• ObjectId structure (12 bytes):

  1. 4-byte Unix timestamp (creation time).

  2. 5-byte random value (per process/machine).

  3. 3-byte incrementing counter.

• Practical benefits:

  • Uniqueness without a central coordinator, ideal for distributed inserts.

  • Embedded timestamp gives approximate insertion order and a free getTimestamp().

MongoDB is an open-source, document-oriented NoSQL database that stores data as flexible JSON-like documents instead of rows in fixed tables, trading rigid schemas and joins for schema flexibility and horizontal scalability.

• Data model:

  • Documents (BSON) with nested fields and arrays vs. flat rows spread across normalized tables.

  • Related data is often embedded in one document rather than joined across tables.

• Schema: Dynamic/flexible: documents in a collection need not share the same fields; RDBMS enforces a fixed schema.

• Scaling: Scales horizontally via sharding across commodity servers; RDBMS traditionally scales vertically.

• Query and relationships:

  • Rich query language and aggregation pipeline; no native multi-table JOINs ($lookup exists but is used sparingly).

  • No foreign-key constraints; integrity is often handled in the application.

BSON (Binary JSON) is the binary-encoded serialization format MongoDB uses to store documents and transfer them over the wire: it extends JSON with more data types and is designed for fast traversal and efficient storage.

• Why not plain JSON:

  • JSON is text-only and lacks types like dates and 64-bit integers; BSON adds them.

  • Length prefixes let the engine skip fields without parsing everything, speeding scans.

• Extra types: Includes ObjectId, Date, Decimal128, binary data, and distinct int/long/double types.

• Trade-offs:

  • Optimized for speed and traversal, not minimum size; small values can be larger than JSON.

  • Individual document size limit is 16 MB.

A document is a single record stored as a set of field-value pairs (like a JSON object), and a collection is a group of documents, roughly analogous to a row and a table in a relational database.

• Document:

  • BSON structure with fields that can hold scalars, arrays, or nested sub-documents.

  • Always has an _id primary key; max size 16 MB.

• Collection:

  • Holds many documents and lives inside a database; created implicitly on first insert.

  • Schema-less: documents in the same collection can have different fields.

• Mapping to RDBMS: Collection ≈ table, document ≈ row, field ≈ column, but with nesting instead of joins.

MongoDB's main advantages come from its flexible document model plus built-in horizontal scaling and high availability, which suit rapidly evolving applications and large, distributed workloads.

• Flexible schema: Add or change fields without migrations, matching agile development.

• Natural data mapping: Documents map cleanly to objects in code, reducing ORM impedance mismatch.

• Horizontal scalability: Sharding distributes data across nodes to handle large volumes and throughput.

• High availability: Replica sets provide automatic failover and redundancy.

• Rich querying and indexing: Powerful aggregation pipeline, secondary/compound/geospatial/text indexes.

• Performance: Embedding related data lets many reads hit a single document, avoiding joins.

MongoDB is a document-oriented NoSQL database that stores data as flexible BSON documents and is designed for scalability, high availability, and developer productivity.

• Document data model: JSON-like documents stored as BSON, with dynamic schemas.

• Replica sets: Automatic replication and failover for high availability.

• Sharding: Built-in horizontal partitioning across nodes for scale-out.

• Aggregation framework: Pipeline of stages ($match, $group, $lookup) for analytics and transformations.

• Indexing: Secondary, compound, text, geospatial, and TTL indexes.

• Other features: Multi-document ACID transactions, change streams, and a managed cloud option (Atlas).

MongoDB stores documents in BSON (Binary JSON), which supports JSON's core types plus extra types needed for databases like precise numeric types, dates, and object identifiers.

• Scalars:

  • String (UTF-8), Boolean, and Null.

  • Numeric: Int32, Int64 (Long), Double, and Decimal128 for exact decimal (financial) values.

• Container types:

  • Object: embedded/nested documents.

  • Array: ordered lists, which can hold mixed types.

• Special BSON types:

  • ObjectId: 12-byte default value for _id.

  • Date (millisecond timestamp) and Timestamp (internal, for replication).

  • BinData (binary), Regex, and MinKey/MaxKey for comparison boundaries.

NoSQL ("not only SQL") is a family of non-relational databases built for flexible schemas and horizontal scale; MongoDB is the leading document-oriented NoSQL database, storing data as JSON-like documents rather than rows in tables.

• NoSQL categories: Document (MongoDB), key-value (Redis), wide-column (Cassandra), and graph (Neo4j).

• Where MongoDB fits:

  • It is a document store: each record is a self-contained BSON document with a flexible structure.

  • No fixed table schema, so fields can differ across documents in the same collection.

• Why NoSQL emerged: To handle large-scale, rapidly changing, semi-structured data and to scale out across commodity servers.

• Caveat: NoSQL isn't "anti-SQL" or always better: it trades some relational guarantees and join power for flexibility and scale.

Dynamic schema means MongoDB does not require documents in a collection to share a predefined structure: you can insert documents with different fields and types without declaring a schema up front, and change shape over time without migrations.

• How it works:

  • Each document carries its own field definitions, so two documents in one collection can have entirely different fields.

  • You can add or remove fields per document simply by writing them.

• Benefits:

  • Fast iteration: no ALTER TABLE-style migrations to add a field.

  • Natural fit for heterogeneous or evolving data.

• Tradeoffs and controls:

  • The application must handle missing or inconsistent fields, so flexibility can become chaos without discipline.

  • When you do want enforcement, use JSON Schema validation via $jsonSchema to constrain structure per collection.

MongoDB is best known as the most popular document database: it stores flexible, JSON-like documents and scales horizontally, making it a go-to choice for developer-friendly, rapidly evolving applications.

• Document model: Stores BSON documents that map cleanly to objects in application code, reducing object-relational friction.

• Flexible/dynamic schema: No rigid table definitions, enabling fast iteration.

• Scalability and availability: Built-in sharding for horizontal scale and replica sets for high availability.

• Rich querying: A powerful query language and the aggregation pipeline for analytics-style processing.

• Ecosystem: managed cloud service Atlas and broad language driver support.

Update operators modify specific fields of a document in place rather than replacing the whole document; $set assigns field values, while $inc, $push, and $pull handle numeric increments and array modifications.

• $set:

  • Sets or overwrites a field's value; creates the field if it doesn't exist.

  • Avoids replacing the entire document (unlike passing a plain document).

• $inc:

  • Atomically increments (or decrements with a negative value) a numeric field.

  • Great for counters like views or stock levels.

• $push: Appends a value to an array (combine with $each to add several).

• $pull: Removes all array elements matching a condition.

• Related: $addToSet (push only if absent), $unset (remove a field), and $pop (remove first/last array element).

You read data with the find() family of methods, passing a query filter document that describes which documents to match and optionally a projection to control which fields come back.

• Core methods:

  • find(filter, projection): returns a cursor over all matching documents.

  • findOne(filter): returns a single document (or null) instead of a cursor.

• The filter document: An empty filter {} matches everything; keys plus operators ($gt, $in) narrow the match.

• Shaping results:

  • Projection: { name: 1, _id: 0 } includes/excludes fields.

  • Cursor modifiers chain on: sort(), limit(), skip().

• Cursors are lazy: documents are fetched in batches only as you iterate.

Dot notation lets you reach into embedded documents and array elements to query or project fields that aren't at the top level, using a "parent.child" string path.

• Nested documents:

  • address.city matches the city field inside an embedded address object.

  • Must be quoted because of the dot: { "address.city": "Paris" }.

• Array elements:

  • By position: { "scores.0": 90 } targets the first element.

  • By field in array of documents: { "items.price": { $gt: 10 } } matches if any element qualifies.

• Important caveat: Multiple dot-notation conditions on an array may match across different elements; use $elemMatch to force all conditions onto one element.

They both modify documents, but update() is a legacy method whose behavior depends on flags, while updateOne() is the modern, explicit method that always updates at most one document.

• update() (deprecated in the shell):

  • Updates one document by default, or many if you pass { multi: true }.

  • Ambiguous: intent isn't clear from the call alone.

• updateOne():

  • Always affects the first matching document only.

  • Part of the CRUD family with updateMany() for explicit multi-document updates.

• Best practice: use updateOne() / updateMany() so the number of affected documents is unambiguous.

find() returns a cursor over all matching documents, while findOne() returns a single document object (the first match) or null.

• find():

  • Returns a lazy cursor you iterate or chain with sort(), limit(), skip().

  • Use when you expect zero-to-many results.

• findOne():

  • Returns one document directly (not a cursor), applying an implicit limit(1).

  • Use when you want a single record, e.g. by unique key.

• Equivalent: findOne(f) is roughly find(f).limit(1) but unwrapped from the cursor.

They combine or negate query conditions. $and requires all clauses, $or requires at least one, $nor requires none, and $not negates a single operator expression.

• $and (all must match):

  • Often implicit: listing multiple fields in one filter already ANDs them.

  • Explicit form is needed when conditions target the same field twice.

• $or (at least one matches): Takes an array of condition documents; matches if any is true.

• $nor (none match): The logical inverse of $or: passes only if every listed condition is false.

• $not (negates one expression):

  • Wraps a single operator expression, not an array: { price: { $not: { $gt: 100 } } }.

  • Also matches documents where the field is missing.

$in matches documents whose field value equals any value in a given array, and $nin is its opposite: it matches documents whose value is not in the array (or where the field is absent).

• $in:

  • { status: { $in: ["A", "B"] } } matches A or B; cleaner than a chain of $or equality checks.

  • For array fields, matches if any element is in the list.

• $nin:

  • { status: { $nin: ["A", "B"] } } excludes A and B.

  • Also returns documents missing the field entirely.

• Performance note: $in can use an index, but $nin is a negation and typically forces a full scan.

An upsert is an update that inserts a new document when no document matches the filter, and otherwise updates the existing match: it's a single atomic "update or insert" operation controlled by the upsert: true option.

• How to enable it: Pass { upsert: true } to updateOne, updateMany, or findOneAndUpdate.

• What the inserted document contains:

  • Fields from the filter's equality conditions plus fields set by the update operators ($set, etc.).

  • Use $setOnInsert to add fields only when an insert actually happens.

• The result tells you what happened: When an insert occurs, the result reports an upsertedId; on a match it reports modifiedCount.

• Common use: idempotent writes and "create-if-absent" logic without a separate read.

Projection controls which fields a query returns, specified as a second argument where fields are marked for inclusion (1) or exclusion (0). You generally cannot mix inclusion and exclusion in the same projection, with one exception: _id.

• Two modes:

  • Inclusion: list only the fields you want ({ name: 1, age: 1 }); everything else is dropped.

  • Exclusion: list only fields to remove ({ password: 0 }); everything else is kept.

• The mixing rule:

  • You can't combine 1 and 0 values in one projection, or you get an error.

  • Exception: _id (included by default) can be suppressed with { name: 1, _id: 0 }.

• Beyond simple fields: Projection also supports operators like $slice, $elemMatch, and computed fields via aggregation expressions.

A single BSON document in MongoDB has a maximum size of 16MB, which keeps individual documents small enough to avoid excessive RAM and bandwidth use during transfer.

• The 16MB BSON limit:

  • Applies to the full serialized document, so large embedded arrays or blobs can push against it.

  • For larger content, use GridFS or external storage.

• Nesting depth limit: BSON documents can be nested at most 100 levels deep.

• Practical guidance: The limit is a design signal: unbounded arrays that grow forever should be referenced into a separate collection rather than embedded.

MongoDB lets you nest related data directly inside a document as embedded sub-documents and arrays, so a single read can return an entity together with its related data without joins.

• What embedding means:

  • Related data lives inside the parent document as nested objects or arrays of objects.

  • The whole entity is retrieved and updated as one atomic unit.

• Why it helps:

  • Reads are fast: no $lookup or application-side joins needed.

  • Writes to a single document are atomic, which simplifies consistency.

• Limits to watch:

  • Embedded data counts against the 16MB document limit, so avoid unbounded growth.

  • Duplicated embedded data must be updated in every copy.

You model a one-to-many relationship based on the cardinality of the "many" side: embed when it's a small, bounded set, and reference when it's large or unbounded.

• One-to-few: embed an array:

  • Store the children directly in an array on the parent (e.g. a person's few addresses).

  • One read gets everything; updates stay atomic.

• One-to-many: reference by id:

  • Keep children in their own collection, each holding the parent's _id as a foreign key (child-referencing).

  • Query children by that field; index it for performance.

• One-to-squillions: parent reference on the child: For huge counts (log lines per host), never store child ids on the parent, only the parent id on each child.

Indexes are ordered data structures (B-trees) that store a subset of a collection's fields so MongoDB can locate matching documents without scanning every document. They turn a full collection scan into an efficient lookup, dramatically speeding up reads.

• Without an index: A query does a COLLSCAN, reading every document: O(n) and slow at scale.

• With an index:

  • MongoDB traverses the B-tree (IXSCAN) to find matching keys, then fetches only those documents.

  • Indexes also support sorts (returning results in index order) and can fully answer covered queries.

• Costs / trade-offs:

  • Each index consumes storage and must be updated on every insert/update/delete, slowing writes.

  • Unused or redundant indexes are pure overhead: index for real query patterns only.

• Verify with tooling: Use explain("executionStats") to confirm an IXSCAN and check documents examined vs. returned.

MongoDB backups can be logical (dump BSON with mongodump) or physical (copy data files or filesystem snapshots), with cloud-managed options for production.

• Logical backup/restore:

  • mongodump writes collections as BSON plus metadata; mongorestore reads it back.

  • Good for smaller datasets and portability; slow and resource-heavy on large clusters.

• Physical / filesystem backup:

  • Copy the dbPath files or take a volume snapshot for fast, whole-cluster restores.

  • Stop writes or use journaling/snapshot consistency to get a valid point-in-time copy.

• Managed backups: Atlas and Ops Manager offer continuous, point-in-time restore without manual tooling.

• Practical tips: Use --gzip and --archive to compress into a single file; use --oplog for a consistent snapshot of a replica set.

MongoDB Compass is the official GUI for exploring, querying, and managing MongoDB visually, aimed at developers and DBAs who prefer a graphical interface over the shell.

• Data exploration:

  • Browse databases and collections, view documents, and edit them inline.

  • Automatic schema analysis shows field types and value distributions.

• Querying and aggregation: Build filters visually and use the Aggregation Pipeline Builder to compose stages step by step.

• Performance tools:

  • View and create indexes, and use explain plans to see query performance.

  • Real-time performance/monitoring panel for operations and slow queries.

• Convenience: Import/export data, and an embedded shell (mongosh) for those who want to drop into commands.

Compass is a graphical GUI for visual exploration; the Shell is a text/command-line interface for scripting and automation. They talk to the same server but suit different workflows.

• Compass (GUI):

  • Point-and-click browsing, visual query and aggregation builders, schema visualization.

  • Best for ad-hoc exploration, learning, and users who prefer visuals.

• Shell (mongosh):

  • Full JavaScript environment for commands, scripts, and administrative tasks.

  • Best for automation, repeatable scripts, CI, and headless servers.

• Overlap: Compass embeds mongosh, so you can use both in one tool; anything Compass does can also be done in the shell.

The Mongo Shell (mongosh) is an interactive JavaScript-based command-line interface for connecting to and operating on a MongoDB deployment.

• What it is:

  • A REPL where you run CRUD operations, aggregations, and admin commands using JS syntax.

  • mongosh is the modern replacement for the legacy mongo shell.

• Primary uses:

  • Ad-hoc queries and data inspection: db.users.find().

  • Administration: creating indexes, managing users, checking replica-set/sharding status.

  • Scripting: load .js files to automate maintenance or migrations.

• Handy features: Full JS: variables, loops, and functions; plus syntax highlighting and autocompletion.

MongoDB Atlas is MongoDB's fully managed cloud database-as-a-service (DBaaS) that runs on AWS, Azure, and GCP: it handles provisioning, scaling, backups, patching, and monitoring so teams use MongoDB without operating the servers.

• What it manages for you:

  • Automated deployment of replica sets and sharded clusters across regions/clouds.

  • Backups, point-in-time recovery, security patches, and version upgrades.

  • Built-in monitoring, alerts, and a performance advisor for index suggestions.

• Why it is widely used:

  • Removes operational burden so developers focus on the application, not infrastructure.

  • Elastic scaling (vertical and horizontal) with high availability by default via multi-node replica sets.

  • Integrated features: Atlas Search, Vector Search, Charts, Data Federation, and Triggers in one platform.

  • Security posture out of the box: encryption at rest/in transit, network isolation, and fine-grained access control.

In MongoDB, a write to a single document is always atomic: all its changes (even across multiple fields, subdocuments, and arrays) either fully apply or not at all, with no partial state visible to other readers.

• Scope of the guarantee: One updateOne touching several fields is atomic; concurrent readers see either the old or new document, never a mix.

• Why it matters for schema design: Embedding related data in one document lets you update it atomically without needing a multi-document transaction.

• The limit: Atomicity does not extend across two separate documents; that requires a transaction.

• Update operators help: Operators like $inc, $push, and findAndModify apply atomically to a document, avoiding read-modify-write races.

Yes: a single-document operation has always been atomic, and since version 4.0 MongoDB also supports full multi-document ACID transactions on replica sets, extended to sharded clusters in 4.2.

• Single-document atomicity:

  • Updates to one document (including embedded sub-documents/arrays) are always all-or-nothing.

  • Good schema design (embedding related data) often removes the need for transactions.

• Multi-document transactions:

  • Available on replica sets (4.0) and sharded clusters (4.2) via a session.

  • Provide snapshot isolation and honor read/write concerns for consistency.

• Caveats: Transactions add performance overhead and have time/size limits; use them selectively.

Choose MongoDB when your data is document-shaped, evolving, and read/written as whole entities; avoid it when your workload depends on multi-table relationships, strong normalization, and rich cross-entity transactional integrity that a relational engine handles natively.

• Choose MongoDB when:

  • Your data maps naturally to nested documents (e.g. a user with embedded profile, settings, activity) and is accessed together.

  • Schema evolves fast or varies per record: flexible/dynamic schema avoids constant migrations.

  • You need horizontal scale-out via sharding and high write throughput.

  • Use cases like catalogs, content, event/IoT data, real-time analytics, and rapid prototyping.

• Avoid MongoDB when:

  • Data is highly relational with many-to-many joins: relational engines and SQL joins are more efficient and expressive.

  • You require heavy multi-document/multi-entity transactions as the norm (MongoDB supports them but they carry more overhead).

  • Strict schema enforcement and rigid data integrity constraints are central to the domain (e.g. finance ledgers).

• Key tradeoffs:

  • Flexibility vs. discipline: dynamic schema speeds development but pushes data-consistency responsibility onto the application.

  • Denormalization vs. joins: embedding gives fast single-read access but risks duplication and update anomalies.

  • Scale vs. relational richness: easy horizontal scaling in exchange for weaker native support for complex joins.

Avoid MongoDB when your workload is fundamentally relational, transaction-heavy across many entities, or demands strict schema and integrity guarantees that a relational database enforces natively and more efficiently.

• Highly relational data: Many-to-many relationships requiring frequent joins are awkward and less efficient than SQL joins.

• Complex multi-document transactions as the core pattern: MongoDB supports ACID transactions across documents, but they add overhead and aren't its sweet spot.

• Strict schema and integrity needs: Domains needing enforced constraints, foreign keys, and normalization (e.g. accounting/banking ledgers).

• Heavy ad-hoc reporting with SQL tooling: Ecosystems and BI tools built around SQL may integrate more smoothly with relational stores.

• Rule of thumb: pick the model that matches your data's shape and access pattern, not the trendiest engine.

find() retrieves documents matching a filter with optional projection and sort; aggregate() runs documents through a multi-stage pipeline that can transform, group, join, and compute, doing far more than simple retrieval.

• find():

  • Filters and returns documents largely as stored (with projection to include/exclude fields).

  • Simple, fast, and ideal for straightforward lookups.

• aggregate():

  • Processes data through ordered stages like $match, $group, $project, $sort, and $lookup (join).

  • Can compute aggregates (sums, averages, counts), reshape documents, and combine collections.

• Rule of thumb:

  • Use find() to fetch documents; use aggregate() when you need to transform or summarize them.

  • Put a $match early in a pipeline so it can use indexes and reduce work downstream.

Both target a single matching document, but updateOne() applies update operators to specific fields, while replaceOne() swaps the entire document (except _id) for a new one.

• updateOne():

  • Requires update operators like $set, $inc, $push.

  • Fields not mentioned are left untouched.

• replaceOne():

  • Takes a plain document (no operators) that becomes the whole document.

  • Any field not in the replacement is lost; _id is preserved.

• Rule of thumb: patch a few fields with updateOne(); overwrite the whole record with replaceOne().

$exists tests whether a field is present in a document, while $type tests the BSON data type of a field's value: they answer "is it there?" versus "what kind of value is it?".

• $exists:

  • { field: { $exists: true } } matches documents that contain the field, even if its value is null.

  • { $exists: false } finds documents missing the field entirely.

• $type:

  • Matches by BSON type using an alias string or number: { age: { $type: "int" } }.

  • Accepts an array to match any of several types: { $type: ["int", "double"] }.

• Combined use: Useful for schema auditing in flexible collections, e.g. finding fields stored as the wrong type.

findOneAndUpdate finds a single document matching the filter, applies an update, and atomically returns one version of that document; the returnDocument option decides whether you get the document before or after the update.

• What it does:

  • Atomically locates one document (using sort if given) and modifies it in a single operation, avoiding read-then-write races.

  • Returns the document itself, not just a count.

• returnDocument values:

  • 'before' (default): returns the original document as it was before the update.

  • 'after': returns the updated document reflecting the changes.

• Legacy note: older drivers used returnNewDocument: true or returnOriginal instead of returnDocument.

• Handy for atomic counters and job queues where you need the resulting value.

$elemMatch matches array documents where at least one single element satisfies all the given conditions together; dot notation instead lets different conditions be satisfied by different elements, which is often not what you want.

• The core difference:

  • $elemMatch: all conditions must hold for the same element.

  • Dot notation with multiple conditions: each condition may be met by a different element in the array.

• When you need it:

  • Use $elemMatch for arrays of subdocuments when combining two-plus criteria (e.g. same item both matches sku and has qty > 5).

  • For a single condition on array elements, plain matching or dot notation is enough; $elemMatch is unnecessary.

• Also usable in projection to return only the first matching array element.

$all matches arrays that contain all of a set of specified values (regardless of order), while $size matches arrays of an exact length. They answer different questions: "contains these" versus "has this many".

• $all:

  • Requires the array to include every listed value; extra elements are fine.

  • Example: find docs whose tags include both "a" and "b".

• $size:

  • Matches an exact element count; it takes a number, not a range, and can't be combined with $gt/$lt.

  • For range-of-length queries, store a separate count field or use $expr with $size.

• Indexing note: $size can't use an index efficiently, whereas $all can leverage a multikey index.

$push appends a value to an array unconditionally (duplicates allowed), while $addToSet adds a value only if it isn't already present, keeping the array set-like. $each lets either operator add multiple values in one operation.

• $push:

  • Always appends, even if the value already exists.

  • Supports modifiers like $sort, $slice, and $position (used with $each).

• $addToSet: Adds only if absent, using deep equality to detect duplicates; no-op if present.

• $each:

  • Wraps an array of values so multiple are added at once.

  • Without $each, passing an array to $addToSet adds the array itself as a single nested element.

A capped collection is a fixed-size collection that acts like a circular buffer: once it fills up, the oldest documents are automatically overwritten to make room for new ones, and insertion order is preserved.

• Fixed size and FIFO eviction:

  • You define a maximum size in bytes (and optionally a max document count); the oldest records are purged first.

  • Documents are kept in natural insertion order, so reads without a sort return them in that order efficiently.

• Behavioral constraints:

  • You cannot delete individual documents, and updates must not grow a document's size.

  • You cannot shard a capped collection.

• Typical uses:

  • Logging, caching, and high-throughput event streams where only recent data matters.

  • MongoDB itself uses a capped collection for the replication oplog.

• Created with an explicit option:

GridFS is a specification for storing and retrieving files larger than the 16MB document limit by splitting a file into smaller chunks and storing them across two collections.

• Two collections work together:

  • fs.chunks: stores the binary pieces of the file, each defaulting to 255KB.

  • fs.files: stores file metadata (filename, length, upload date, content type).

• How chunking works:

  • A file is divided into ordered chunks, each a separate document linked back to a file id.

  • On read, the driver reassembles chunks in order, and can stream ranges without loading the whole file.

• When to use it:

  • Files exceeding 16MB, or when you want to fetch parts of a file without loading it entirely.

  • For small files, storing binary directly in a document (or using external object storage) is often simpler and faster.

Embedding nests related data inside a single document, while referencing stores related data in separate documents linked by id; you embed when data is accessed together and bounded, and reference when data is large, shared, or grows without limit.

• Embedding:

  • Best for one-to-one and one-to-few relationships accessed together.

  • Single-read retrieval and atomic single-document updates.

  • Avoid when the embedded data grows unbounded or is shared across many parents.

• Referencing:

  • Store an id (or array of ids) pointing to documents in another collection.

  • Best for many-to-many, large sub-entities, or data reused by many documents.

  • Requires a second query or $lookup and updates are not atomic across documents.

• Deciding factor: Ask how the data is queried together, how large it gets, and how often it changes: model for your read/write patterns.

In MongoDB you design the schema around how the application queries and updates data, not around normalized entities: the guiding principle is that data accessed together should be stored together.

• Model to your access patterns:

  • Start from the queries and writes the app makes, then shape documents to serve them with fewest round trips.

  • This is the opposite of relational "design entities first, then join."

• Embed vs reference:

  • Embed bounded, together-accessed data for single-read performance and atomic updates.

  • Reference large, shared, or unbounded data to respect the 16MB limit.

• Controlled denormalization: Duplicating fields to avoid joins is acceptable; weigh faster reads against the cost of keeping copies consistent.

• Flexible but not chaotic: A flexible schema eases evolution, but keep a consistent structure and enforce it with schema validation where it matters.

• Respect limits and indexing: Avoid unbounded array growth and design fields so the queries you run can be indexed effectively.

Model many-to-many by storing arrays of references on one or both sides, or by embedding when one side is small and bounded; the right choice depends on cardinality and query direction.

• Two-way referencing with arrays:

  • e.g. a student holds course_ids: [] and a course holds student_ids: [], so you can query from either side.

  • Duplicating both directions costs write consistency: adding an enrollment updates two documents.

• One-way referencing: Store the array only on the side you query most; resolve the reverse direction with a query on the array field (backed by a multikey index).

• Embedding for small, bounded sides: If one entity has few related items and they're read together, embed a subset; avoid unbounded arrays that break the 16MB limit.

• Junction/link collection: For rich relationships (extra attributes like enrollment date or grade), use a separate collection with student_id and course_id, similar to a relational join table.

MongoDB's flexible document model is a natural fit for unstructured/semi-structured data: documents don't require a fixed schema, so varied shapes coexist in one collection while you still enforce structure where it matters.

• Leverage flexible BSON documents: Nested objects and arrays map cleanly to JSON-like sources (logs, APIs, sensor feeds) with no upfront migration.

• Use the Polymorphic and Attribute patterns: A type discriminator field lets differently-shaped docs live together; sparse/optional fields are handled naturally.

• Enforce guardrails where needed: Apply $jsonSchema validation rules to require key fields and types while leaving the rest open.

• Index intelligently: Use partial/sparse indexes for fields present only on some documents, and wildcard indexes when field names are unpredictable.

• Model to access patterns, not source shape: Even with messy input, normalize the fields you query on and store the raw payload alongside if needed.

Model a product's variations as an embedded array of variant documents, each representing a concrete sellable combination (a SKU) with its own price, stock, and attributes: the variants are bounded and always read with the product, so embedding is ideal.

• Parent product holds shared data: Name, description, brand, base images: attributes common to all variations.

• Variants array holds per-SKU data: Each entry has its sku, size, color, price, and stock.

• Index the variant fields: A multikey index on variants.sku or variants.color supports lookups by variation.

• When to split out: If variant count is huge or inventory is updated at extreme frequency, promote SKUs to their own collection to avoid rewriting a large parent document.

Because documents are schema-flexible, MongoDB lets you evolve schemas without downtime: you add or change fields freely and reconcile old and new shapes either lazily on read or eagerly with a migration.

• Versioned documents (Schema Versioning Pattern): Tag each document with a schema_version field so application code knows how to interpret it.

• Lazy migration (migrate-on-read): App handles multiple versions; when an old doc is read or updated, transform it to the new shape and save. Spreads cost over time.

• Eager migration (bulk): Run an updateMany or aggregation $merge to backfill all documents at once; simpler mental model but a heavy one-time write.

• Enforce with validation gradually: Introduce or tighten $jsonSchema rules with validationLevel (e.g. moderate) so only new/updated docs are checked.

• Additive changes are cheapest: Adding optional fields needs no migration; renames and type changes are what require a strategy.

Reference resolution is the process of following a stored reference (an id in one document) to fetch the related document(s) it points to: MongoDB has no automatic foreign keys, so this happens either in the application or server-side with $lookup.

• Application-side resolution: Read the parent, then issue a second query for the referenced ids. Simple and explicit; costs an extra round-trip.

• Server-side with $lookup: An aggregation stage that joins another collection on a matching field, returning results in one query (a left outer join).

• Manual references vs DBRefs:

  • Manual reference: just store the _id and resolve it yourself (preferred).

  • DBRef: a formal { $ref, $id } convention, rarely used and still resolved by the client.

• Design tradeoff: Every resolution is a cost; the Extended Reference Pattern denormalizes hot fields so common reads skip the join entirely.

A TTL index is a special single-field index on a date field that lets MongoDB automatically delete documents once they reach a specified age, without you running cleanup jobs. It's ideal for ephemeral data like sessions, logs, or caches.

• How it works:

  • Create it with expireAfterSeconds on a field holding a Date.

  • A background thread runs about every 60 seconds and removes documents whose field + expireAfterSeconds is in the past.

• Key rules:

  • The indexed field must be a BSON Date (or an array of dates: the earliest is used); non-date values are ignored.

  • Only works on a single-field index, not compound.

  • Set expireAfterSeconds: 0 to expire exactly at the timestamp stored (useful for explicit expiry dates).

• Caveats:

  • Deletion is not instant: there's up to ~60s (plus load) lag.

  • On replica sets, deletes happen on the primary and replicate normally.

Create a single compound index on customer then date: { customerId: 1, orderDate: -1 }. It serves both "orders for a customer" and "orders for a customer in a date range" (with sorting), because a compound index also serves queries on its leftmost prefix.

• Why this order (the ESR rule):

  • Equality first: customerId is matched exactly, narrowing the range.

  • Range/Sort next: orderDate handles the date range and lets results come back already sorted (descending for newest-first).

• What it covers:

  • find({ customerId }) uses the left prefix.

  • find({ customerId, orderDate: { $gte, $lte } }) uses both fields.

  • sort({ orderDate: -1 }) is satisfied by the index, no in-memory sort.

• If you also query by date alone: The compound index won't help (orderDate isn't a prefix); add a separate { orderDate: -1 } index for global date-range queries.

A compound index is a single index built on two or more fields, storing entries sorted by those fields in the declared order. Use one when queries filter or sort on multiple fields together.

• Definition: Created with e.g. db.coll.createIndex({ a: 1, b: -1 }); field order and sort direction both matter.

• When to use:

  • Queries that filter on several fields at once, or filter on one and sort on another.

  • Covered queries: if all queried and returned fields live in the index, MongoDB answers from the index without touching documents.

• Key considerations:

  • Order fields by the ESR rule (Equality, Sort, Range) for best performance.

  • A single compound index can replace several single-field indexes thanks to the prefix rule.

Geospatial indexes let MongoDB efficiently query location data: finding documents near a point, within a shape, or intersecting a geometry. There are two types depending on whether you model a flat plane or the earth's sphere.

• 2dsphere:

  • For earth-like spherical geometry using GeoJSON (Point, Polygon, etc.); accounts for curvature.

  • Supports $near, $geoWithin, and $geoIntersects.

• 2d: For legacy coordinate pairs on a flat plane; used mainly for older data or simple planar queries.

• Usage: Store GeoJSON, create the index, then run proximity/containment queries; distance can be returned and sorted.

A partial index only indexes documents that match a specified filter expression, while a sparse index only indexes documents where the field exists. Partial indexes are the more general, modern feature and can express sparse behavior and much more.

• Partial index:

  • Defined with partialFilterExpression; indexes only docs meeting arbitrary conditions (e.g. rating: { $gt: 4 }).

  • Smaller and cheaper; great for indexing a hot subset of data.

• Sparse index:

  • Skips documents that lack the indexed field entirely.

  • Essentially a special case of partial with $exists: true.

• Key difference and caveat:

  • Partial is more flexible and generally preferred; MongoDB recommends it over sparse.

  • A partial index is only used when the query is guaranteed to match documents included in the index, else the planner ignores it.

Collation defines language-specific string comparison rules (case, accents, ordering). A case-insensitive index is just an index built with a collation whose strength ignores case, letting equality and sort queries match regardless of capitalization.

• Collation fields: locale sets the language rules; strength controls sensitivity (1 = base letters, 2 = + accents, 3 = + case, the default).

• Case insensitivity: Set strength: 2 so "Cafe" and "cafe" compare equal.

• Matching rules:

  • A query uses a collated index only when the query's collation matches the index's collation.

  • Can be set at collection, index, or per-operation level; operation-level overrides the default.

• Benefit: Avoids the slow alternative of regex or normalizing/lowercasing a duplicate field for case-insensitive search.

A multikey index is an index on a field that holds an array; MongoDB automatically creates one separate index entry for each element of the array, letting queries match on any element.

• Automatic behavior:

  • You don't declare it specially: any standard index becomes multikey the moment it indexes an array value.

  • One document with a 3-element array produces 3 index entries pointing back to it.

• Query support: Efficiently supports equality and $elemMatch queries against array contents.

• Restrictions:

  • A compound index can include at most one array field: indexing two arrays together would create a combinatorial explosion of entries.

  • Multikey indexes can't be used as covering indexes for the array field and have some sort limitations.

An aggregation pipeline is a sequence of stages that transform documents step by step, with each stage's output feeding the next, used for filtering, grouping, reshaping, and computing analytics server-side.

• How it flows: Documents pass through ordered stages like a conveyor belt; each stage does one transformation.

• Common stages:

  • $match filters (use it early to leverage indexes), $group aggregates, $project reshapes fields.

  • $sort, $limit, $lookup (joins), and $unwind (flatten arrays).

• Why use it: Computation happens in the database, avoiding pulling raw data to the app; it replaces most needs for map-reduce.

Map-reduce is an older data-processing feature where you write JavaScript map and reduce functions to aggregate data; the aggregation framework has largely replaced it as the faster, easier alternative.

• How map-reduce works: map emits key-value pairs per document; reduce combines values sharing a key; an optional finalize post-processes.

• Why aggregation is preferred:

  • Pipelines run as optimized native operators (C++) rather than interpreted JavaScript, so they're much faster.

  • Pipeline syntax is more declarative and maintainable.

• Status: mapReduce is deprecated in favor of the aggregation pipeline; use it only for rare custom JavaScript logic that stages can't express.

MongoDB performs join-like operations with the $lookup aggregation stage, but idiomatic MongoDB often avoids joins entirely by embedding related data through schema design.

• $lookup (the join equivalent):

  • Performs a left outer join, matching a local field to a foreign field in another collection and adding matches as an array.

  • Best when the joined collection is indexed on the foreign field.

• Data modeling: embedding vs referencing:

  • Embed related data in one document when it's accessed together and bounded in size: no join needed.

  • Reference (and $lookup) when data is large, shared, or changes independently.

• Guiding principle: Model around access patterns; joins are possible but denormalization is often the more scalable choice.

$unwind deconstructs an array field, producing one output document per array element so you can process elements individually in later stages.

• Array to documents: A document with an array of N elements becomes N documents, each with a single (non-array) value in that field.

• Common use: Flatten arrays before grouping, matching, or joining on individual elements.

• Empty/missing handling:

  • By default, empty arrays, missing fields, or nulls drop the document; use preserveNullAndEmptyArrays: true to keep them.

  • includeArrayIndex can attach the element's original index.

Both aggregate documents into groups, but $group groups by any expression/key while $bucket groups documents into ranges (buckets) based on numeric or comparable boundaries.

• $group:

  • Groups by an arbitrary _id key and computes accumulators ($sum, $avg, $push).

  • One group per distinct key value: good for categorical grouping.

• $bucket:

  • Groups by falling within explicit boundaries you define, producing histogram-style buckets.

  • Needs a default bucket for values outside the ranges, else it errors.

• Related: $bucketAuto: Automatically computes boundaries to distribute documents evenly across a requested number of buckets.

Both are pairs of export/import tools, but mongodump/mongorestore work with binary BSON for full-fidelity backups, while mongoexport/mongoimport work with human-readable JSON/CSV for data interchange.

• mongodump / mongorestore:

  • BSON format preserves all types exactly (dates, ObjectId, Decimal128) plus indexes and metadata.

  • Intended for backup and restore of whole databases.

• mongoexport / mongoimport:

  • JSON/CSV output that other systems can read; some type fidelity is lost.

  • Intended for data exchange with external tools, not reliable backups.

• Rule of thumb: Backups: use dump/restore. Sharing data or loading a CSV: use export/import.

admin, local, and config are reserved system databases MongoDB uses internally for administration, per-node data, and sharding metadata.

• admin:

  • Holds users, roles, and privileges; authenticating here can grant cluster-wide rights.

  • Target for admin-only commands and server-wide operations.

• local:

  • Stores data specific to a single node and is never replicated.

  • Contains the replication oplog (oplog.rs) and startup info.

• config:

  • Used by sharded clusters to store metadata about chunks and shard distribution.

  • Managed automatically; don't modify it manually.

A driver is the client library that lets your application language talk to MongoDB over the wire; an ODM like Mongoose sits on top of the driver to add schemas, validation, and modeling conveniences.

• What a driver does:

  • Serializes queries to the MongoDB wire protocol (BSON) and deserializes responses to native objects.

  • Manages connection pooling, server discovery, retries, and read/write concerns.

  • Exposes CRUD and aggregation APIs directly, with no imposed schema.

• When to use an ODM (Mongoose):

  • You want enforced schemas, type casting, and validation at the app layer.

  • You want middleware/hooks, virtuals, and relationship helpers like populate().

• When to stay on the native driver: You want maximum performance and control, flexible/evolving schemas, or minimal abstraction overhead.

populate() is a Mongoose feature that automatically replaces a referenced ObjectId in one document with the actual document(s) it points to, giving a join-like result across collections.

• How referencing works: You store an ObjectId with a ref to another model instead of embedding the whole document.

• What populate does:

  • At query time it fetches the referenced documents and swaps them in for the stored IDs.

  • Under the hood it runs extra queries (often via $in), not a single server-side join.

• Trade-offs:

  • Keeps data normalized and avoids duplication, but adds query round-trips.

  • For heavy joins consider embedding or $lookup in an aggregation instead.

A connection pool is a cache of reusable open connections the driver maintains to the MongoDB cluster, so operations borrow an existing connection instead of paying the cost of opening a new one each time.

• How it works:

  • The driver opens connections lazily up to maxPoolSize (default 100) per server.

  • An operation checks out a connection, uses it, then returns it to the pool for reuse.

  • If all connections are busy, requests wait until one frees up (or time out via waitQueueTimeoutMS).

• Why it matters:

  • Opening a connection involves a TCP handshake plus auth, so reuse dramatically cuts latency.

  • It bounds concurrency and protects the server from connection storms.

• Common pitfall:

  • Create ONE client and reuse it for the app's lifetime; creating a new client per request exhausts pools and floods the server.

  • In serverless, tune maxPoolSize down and cache the client across invocations.

Atlas shifts the developer's focus away from low-level server administration toward configuration, cost/performance tuning, and using platform features: the database still needs to be understood, but you manage it through the Atlas control plane rather than the shell and OS.

• Skills that become less critical: Manually configuring replica sets, running backups, applying OS patches, and setting up monitoring agents: Atlas automates these.

• Skills that become more important:

  • Data modeling and query/index design, which still determine performance regardless of who runs the servers.

  • Reading Atlas metrics and the Performance Advisor to interpret bottlenecks.

  • Cluster-tier sizing and cost management, since scaling is a click away but has a bill.

  • Configuring security: network access lists, roles, and encryption settings.

• Net effect: Less "DBA sysadmin" work, more "application data architect" and platform-configuration work.

Schema validation lets you enforce rules on documents in a collection at write time, giving MongoDB's flexible model optional structure guarantees. You attach a $jsonSchema (or query-style) validator to a collection, and MongoDB rejects or warns on writes that don't conform.

• Where it lives: Defined per-collection via the validator option in createCollection or collMod.

• What you can enforce:

  • Required fields, BSON types, value ranges/enums, patterns, and nested/array structure with $jsonSchema.

  • Query operators ($or, $and, etc.) can also be used as validation expressions.

• Behavior tuning: Controlled by validationLevel (which docs are checked) and validationAction (reject vs. warn).

• Why use it: Prevents malformed data without moving all validation into the app, while keeping schema flexibility where you want it.

MongoDB supports full-text search either through a local text index queried with $text, or through the far more powerful Atlas Search (Lucene-based) for production-grade search. The built-in text index handles basic keyword search; Atlas Search adds analyzers, fuzzy matching, and relevance tuning.

• Built-in text index:

  • Create with db.coll.createIndex({ field: "text" }); one text index per collection (can span multiple fields).

  • Query with $text and $search; supports stemming, stop words, phrase search, and negation.

  • Rank results using the textScore metadata field.

• Atlas Search:

  • An Apache Lucene index queried via the $search aggregation stage.

  • Adds custom analyzers, fuzzy/autocomplete, faceting, highlighting, and fine-grained scoring: the recommended choice for real search.

• Limitations of the built-in index: Only one text index per collection, limited language/analyzer control, and coarse relevance compared with Atlas Search.

Mongoose is an ODM that layers an application-level schema on top of MongoDB's schemaless collections. A Schema defines shape and rules, a Model is the compiled constructor you use to query/create documents, and validators enforce those rules in your app before data reaches the database.

• Schema: Declares fields, types, defaults, and options; maps to a collection's document structure.

• Model: Created via mongoose.model(name, schema); provides find, create, save, etc., and instances are documents.

• Validators: Built-in (required, min, enum) and custom functions run on save/validate.

• Relation to MongoDB's flexibility:

  • MongoDB itself imposes no schema; Mongoose enforces one in the application layer, giving structure and convenience without a DDL.

  • It complements (not replaces) server-side $jsonSchema validation: Mongoose can be bypassed by other clients, so critical rules may still belong in the DB.

bulkWrite sends multiple write operations (inserts, updates, deletes) to the server in a single call, reducing round trips. You choose ordered or unordered execution, which controls whether the batch stops at the first error and whether operations can run in parallel.

• Ordered (default):

  • Operations run sequentially in the given order; on the first error the batch stops and remaining ops are skipped.

  • Use when later operations depend on earlier ones.

• Unordered ({ ordered: false }):

  • An error on one op does not stop the others; MongoDB may execute them in any order and in parallel, then reports all errors together.

  • Faster and more resilient for independent operations.

• Shared traits: Returns counts (inserted, matched, modified, deleted) and any write errors; is not a transaction unless run inside one.

A cursor is a server-side pointer to the result set of a query; find returns a cursor rather than all documents at once, and the driver pulls results in batches as you iterate. This keeps memory usage bounded and avoids sending huge result sets in a single response.

• How iteration works:

  • The first batch comes back with the initial query; subsequent batches are fetched with getMore as you consume documents.

  • The driver handles this transparently when you loop with forEach, for await, or toArray.

• Batch sizing: First batch defaults to ~101 documents or 16MB, later batches up to 16MB; tune with batchSize().

• Lifecycle and timeout:

  • Idle cursors time out after 10 minutes by default; noCursorTimeout disables that (use carefully).

  • Cursors consume server resources, so exhaust or close them.

• Caution: toArray() loads the whole result into memory, defeating the streaming benefit for large sets.

Role-based access control (RBAC) grants privileges through roles rather than to users directly: a role is a set of privileges (actions on resources), and users are assigned one or more roles.

• How it works:

  • A privilege pairs an action (e.g. find, insert) with a resource (a database, collection, or cluster).

  • Roles can inherit from other roles, and a user's effective permissions are the union of all assigned roles.

  • Roles are scoped to a database, but can grant access across databases.

• Built-in roles:

  • Predefined common roles: read, readWrite, dbAdmin, userAdmin, and cluster/admin roles like clusterAdmin and root.

  • Cover most standard needs without configuration.

• Custom roles:

  • Created with createRole when built-ins are too broad; you define exact privileges for least-privilege access.

  • Useful for granting a specific action on a specific collection only.

Hardening means reducing the attack surface through authentication, network isolation, encryption, and least privilege; an exposed mongod with no auth is one of the most common causes of data breaches and ransomware.

• Enable authentication and authorization: Run with --auth and apply least-privilege RBAC roles to every user.

• Restrict network exposure: Bind to private interfaces with bindIp, use firewalls/security groups, and keep the DB in a private subnet.

• Encrypt data: TLS/SSL for data in transit and encryption at rest (WiredTiger encryption in Enterprise).

• Operational hygiene: Patch regularly, enable auditing, run as a non-root OS user, and disable unused features (e.g. server-side JavaScript).

• Why never expose to the internet:

  • A publicly reachable port lets attackers scan and connect; if auth is off or weak, they can read, wipe, or ransom your data instantly.

  • Even with auth, exposure invites brute-force and exploit attempts; databases belong behind the application tier, not on the open internet.

The localhost exception is a bootstrapping mechanism: when access control is enabled but no users exist yet, MongoDB lets you connect from localhost to create the very first user.

• Purpose: Without it, enabling auth before creating any admin would lock you out entirely (chicken-and-egg problem).

• How it behaves:

  • Only active on connections from the local host, and only while the user database is empty.

  • It closes automatically once the first user is created; after that you must authenticate.

• Best practice: use it once to create an admin user with userAdmin or root, then use normal auth thereafter.

Sharding is MongoDB's method of horizontal scaling: it partitions a collection's data across multiple servers (shards) so no single machine holds the whole dataset or handles all the load.

• Components of a sharded cluster:

  • Shards: each holds a subset of the data (each is typically a replica set).

  • Config servers: store metadata about which data lives on which shard.

  • mongos routers: route queries to the right shard(s) based on the shard key.

• When to use it:

  • Data volume exceeds a single server's storage or working set exceeds its RAM.

  • Write or read throughput exceeds what one replica set can handle.

• Caveat: sharding adds operational complexity, so scale vertically or add replicas first; shard only when a single node genuinely can't cope.

Horizontal scalability (scaling out) means adding more machines to share the load, rather than making one machine bigger (vertical scaling); MongoDB implements it through sharding.

• Horizontal vs vertical:

  • Vertical: bigger CPU/RAM/disk on one server, bounded by hardware limits and cost.

  • Horizontal: many commodity servers, capacity grows by adding nodes.

• How MongoDB implements it:

  • Data is split into chunks by the shard key and distributed across shards.

  • The balancer migrates chunks to keep shards evenly loaded as data grows.

  • mongos routers spread reads and writes across shards, so throughput scales with the number of shards.

• Benefit: near-linear capacity growth for both storage and throughput when the shard key distributes load well.

Replication copies the same data to multiple nodes for availability and redundancy, while sharding splits different data across nodes for scalability; they solve different problems and are often used together.

• Replication:

  • A replica set keeps identical copies of the data: one primary, several secondaries.

  • Goal: high availability, failover, and read redundancy, not more capacity.

• Sharding:

  • Distributes distinct portions of the dataset across shards.

  • Goal: scale storage and throughput beyond one server.

• Combined in practice: Each shard is itself a replica set, so you get scalability and fault tolerance together.

Vertical scaling adds more power (CPU, RAM, disk) to a single server, while horizontal scaling (sharding) spreads data and load across many servers: MongoDB is designed for horizontal scaling once one machine can no longer hold the working set.

• Vertical scaling (scale up):

  • Bigger single machine: simple, no app changes, but has a hard ceiling and gets expensive.

  • Single point of failure unless combined with replication.

• Horizontal scaling (scale out / sharding):

  • Partitions data across shards by a shard key; capacity grows by adding shards.

  • Requires choosing a good shard key and adds operational complexity (mongos, config servers, balancer).

• Rule of thumb: Scale up first (it's simpler); shard when data size or throughput exceeds what one node can serve.

A replica set is a group of mongod instances holding the same data: one primary that takes writes and one or more secondaries that replicate it. This redundancy provides high availability by automatically promoting a secondary if the primary fails.

• Roles:

  • Primary: receives all writes and by default all reads.

  • Secondaries: asynchronously copy the primary's oplog to stay in sync and can serve reads if allowed.

  • Arbiter (optional): votes in elections but holds no data; used to break ties cheaply.

• How it ensures high availability:

  • Members constantly send heartbeats; if the primary is unreachable, an election picks a new primary automatically.

  • Data redundancy means a lost node doesn't lose data as long as a majority survives.

• Recommended topology: An odd number of voting members (e.g. 3) so a majority can always be established.

• Durability: Use write concern w: "majority" so an acknowledged write survives a failover.

Failover is the automatic process where a replica set detects a downed primary and elects a secondary to take over, keeping the set writable with minimal downtime.

• Detection: Members exchange heartbeats every 2 seconds; if a primary misses them past electionTimeoutMillis (default 10s), it's considered unavailable.

• Election: Eligible secondaries call for an election; the one with the most up-to-date oplog and highest priority that wins a majority of votes becomes primary.

• Old primary rejoins: When the failed node returns, it becomes a secondary and rolls back any writes not replicated to the majority.

• Client behavior: Drivers are replica-set aware, detect the new primary, and retry writes (retryable writes) after a brief unavailable window.

• Data safety: Writes acknowledged with w: "majority" won't be lost in the rollback because a majority already had them.

The oplog (operations log) is a special capped collection in the local database where the primary records every write that modifies data. It is the backbone of replication: secondaries tail it and replay its entries to stay in sync.

• What it stores: An ordered stream of idempotent operations, each with a timestamp, so applying them repeatedly is safe.

• Capped and fixed-size:

  • Lives at local.oplog.rs; oldest entries roll off as new ones arrive.

  • Its window (how much history it holds) must exceed how long a secondary might be offline.

• Why it matters:

  • Replication: secondaries tail it to converge on the primary's state.

  • Recovery: a lagging node catches up by replaying missed oplog entries; if it falls beyond the window it needs a full resync.

  • Change streams and PITR backups are built on top of the oplog.

Change streams let applications subscribe to a real-time feed of data changes (inserts, updates, deletes) on a collection, database, or whole deployment, without polling. They are built on the oplog but exposed through a clean, resumable API.

• How they work:

  • Open with watch(); the driver returns change events as documents describing each operation.

  • Backed by the oplog, so they require a replica set (or sharded cluster).

• Key features:

  • Resumable: each event carries a resumeToken so you can restart exactly where you left off after a disconnect.

  • Filterable: you can pass an aggregation pipeline (e.g. $match) to receive only relevant changes.

  • fullDocument option returns the complete updated document, not just the delta.

• When to use them:

  • Event-driven pipelines, cache invalidation, syncing to search engines or data warehouses, and real-time notifications.

  • A safer alternative to tailing the oplog directly.

Write concern specifies the level of acknowledgment MongoDB requires before considering a write successful, letting you trade latency for durability.

• The w option (how many nodes must acknowledge):

  • w: 1: only the primary acknowledges (fast, but a failover could lose it).

  • w: "majority": a majority of replica set members acknowledge, so the write survives failover (durable).

• The j option (journaling): j: true waits until the write is committed to the on-disk journal, protecting against a crash.

• The wtimeout option: Caps how long to wait for acknowledgment; on timeout you get an error even though the write may still eventually apply.

• Durability vs consistency link:

  • Higher write concern (majority + j: true) means acknowledged data won't be rolled back, and pairs with readConcern: "majority" for consistent reads.

  • Lower write concern is faster but risks silent data loss on failover.

MongoDB supports multi-document ACID transactions (since 4.0 for replica sets, 4.2 for sharded clusters), so a group of operations across documents and collections either all commit or all abort.

• How they work:

  • You start a session, call startTransaction(), run operations, then commitTransaction() or abortTransaction().

  • They use snapshot isolation and hold locks; uncommitted changes aren't visible to others.

• When to use them: When a single logical change spans multiple documents that must stay in sync (e.g. transferring funds between accounts).

• When NOT to use them:

  • They carry performance overhead; prefer embedding related data in one document so a single-document write is naturally atomic.

  • Transactions have limits (e.g. a default 60-second runtime) and should be short.

• Rule of thumb: treat multi-document transactions as an escape hatch, not the default. Good schema design removes most of the need.

MongoDB is strongly consistent by default: reads and writes go to the primary of a replica set, but it exposes tunable consistency through read/write concerns and read preferences so you can relax it for scalability.

• Primary-based writes: All writes go to the primary; secondaries replicate the oplog asynchronously.

• Read preference controls the tradeoff: Reading from the primary gives strong consistency; reading from secondaries gives eventual consistency (may lag).

• Read/write concern tune the guarantees: writeConcern: "majority" plus readConcern: "majority" ensure you only read data that won't be rolled back.

• Causal consistency: Client sessions can guarantee read-your-own-writes and monotonic reads across operations.

Use ACID transactions only when a single business operation must atomically modify multiple documents (or collections) that cannot be modeled in one document.

• Good candidates:

  • Financial transfers: debit one account and credit another as one unit.

  • Order + inventory: decrement stock and create the order together.

  • Any cross-document invariant that must never be seen half-applied.

• Avoid when:

  • The related data can be embedded in one document, since single-document updates are already atomic.

  • High-throughput paths where transaction overhead and lock contention hurt performance.

• Design first, transact second: reach for embedding or references before transactions, and keep any transaction short.

ACID stands for Atomicity, Consistency, Isolation, and Durability. MongoDB guarantees them for single-document writes always, and for multi-document operations only inside an explicit transaction.

• Atomicity: All operations in the transaction commit together or roll back together.

• Consistency: The database moves from one valid state to another; committed data respects your invariants.

• Isolation: Transactions use snapshot isolation, so uncommitted changes aren't visible to other operations.

• Durability: With writeConcern: "majority", a committed transaction survives failures and isn't rolled back on failover.

• Applied to multi-document ops:

  • Without a transaction, each document write is independently atomic but the group is not.

  • Wrapping them in a session-based transaction extends all four properties across documents and collections.

You optimize MongoDB across three layers: the schema (model for your access patterns), indexing (support your queries), and infrastructure (RAM, hardware, sharding), then verify with profiling and explain().

• Schema design:

  • Embed data read together to avoid joins; reference data that grows unbounded or is shared.

  • Model around query patterns, not normalization rules.

• Indexing:

  • Create indexes matching query and sort predicates; follow the ESR rule (Equality, Sort, Range) for compound indexes.

  • Use covered queries so results come from the index alone; drop unused indexes (they slow writes).

• Working set in RAM: Keep frequently accessed data plus indexes in memory to avoid disk I/O in the WiredTiger cache.

• Query shape: Project only needed fields, use limit(), and push filters early in aggregation pipelines.

• Scaling: Read replicas for read scaling; shard on a good key for horizontal write/data scaling.

• Measure: Use the database profiler, explain(), and slow-query logs to find real bottlenecks before tuning.

You monitor MongoDB with built-in commands and tools for real-time and historical metrics, the database profiler for slow queries, and logs for errors, correlating them to spot bottlenecks like lock contention, cache pressure, or replication lag.

• Real-time tools:

  • mongostat for ops/sec and cache stats; mongotop for per-collection read/write time.

  • db.currentOp() to inspect and killOp() long-running operations.

• Server metrics:

  • db.serverStatus(): connections, WiredTiger cache usage, locks, and memory.

  • rs.status() for replica set health and replication lag.

• Query diagnosis: The database profiler logs slow ops to system.profile; combine with explain() to see why a query is slow.

• Logs and platforms:

  • Slow-query and error entries in the mongod log.

  • Dashboards via Atlas monitoring, Ops/Cloud Manager, or Prometheus/Grafana for trends and alerts.

• What to watch: cache eviction pressure, growing replication lag, high lock/queue times, and connection saturation.

Both appear in the winningPlan stage of explain(): a COLLSCAN reads every document in the collection, while an IXSCAN walks an index to jump straight to matching keys. Seeing a COLLSCAN on a large collection is usually a red flag for a missing index.

• COLLSCAN (collection scan):

  • Examines all documents; work grows linearly with collection size.

  • Used when no usable index exists for the query predicate.

• IXSCAN (index scan):

  • Traverses a B-tree index, so it inspects only relevant keys.

  • Often followed by a FETCH stage to load full documents, unless the query is covered by the index.

• What to look for:

  • Compare totalKeysExamined and totalDocsExamined against nReturned: ideal ratio is close to 1:1.

  • A COLLSCAN examining thousands of docs to return a few signals a needed index.

The database profiler records the execution details of operations (query shape, duration, docs examined) into the system.profile capped collection per database, letting you identify slow or inefficient queries in a running system.

• Profiling levels:

  1. Level 0: off (default).

  2. Level 1: log only operations slower than a threshold (slowms, default 100ms).

  3. Level 2: log all operations (useful for debugging, noisy in production).

• Enabling it: Set with db.setProfilingLevel(1, { slowms: 50 }).

• Analyzing results: Query system.profile for high millis or high docsExamined, then run explain() on those shapes.

• Caveat: profiling adds overhead; use targeted thresholds in production and prefer level 1.

The main challenge is a mindset shift: moving from normalized relational tables with joins and rigid schemas to a document model where data is often embedded and denormalized, alongside practical concerns around transactions, migration tooling, and query rewriting.

• Data modeling change:

  • Decide when to embed (one-to-few, read together) vs reference (one-to-many, large or shared data).

  • Normalized schemas don't map 1:1; you model around access patterns, not entities.

• Joins and relationships: No native cross-collection joins beyond $lookup; heavy relational logic must be redesigned.

• Transactions: Multi-document ACID transactions exist but are costlier; good document design often removes the need.

• Data migration and integrity: ETL to transform rows into documents; foreign-key constraints must be enforced in the application.

• Team and tooling: Rewriting SQL queries, retraining developers, and adapting reporting tools built for tabular data.

Migrating from a relational database to MongoDB is not a row-for-row copy: you redesign the schema around access patterns, embedding related data that was previously spread across normalized tables, then extract, transform, and load the data while validating correctness.

1. Analyze the relational schema and access patterns: Map tables, foreign keys, and joins, but focus on how the application actually reads and writes data: MongoDB modeling follows queries, not normalization.

2. Design the document model:

   • Embed data that is read together and has a contained lifecycle (e.g. order line items inside an order).

   • Reference data that is large, shared, or independently updated (e.g. link many orders to a customer by _id).

3. Extract, transform, load (ETL): Pull rows from the source, reshape joined rows into nested documents, and insert them: use a custom script, an ETL tool, or mongoimport for JSON/CSV.

4. Add indexes and validation: Create indexes matching query patterns and optionally apply JSON Schema validation to enforce structure.

5. Validate and cut over: Reconcile counts and spot-check documents, run the app against MongoDB, and for zero-downtime use dual writes or change-data-capture before the final switch.

MongoDB scales to large datasets primarily through horizontal scaling (sharding), which partitions a collection across many servers, combined with efficient indexing, a memory-mapped storage engine, and an aggregation pipeline designed to process data close to where it lives.

• Sharding for horizontal scale:

  • Data is split by a shard key into chunks spread across shards, so storage and throughput grow by adding machines rather than a single bigger one.

  • A mongos router directs queries; a good shard key spreads writes evenly and enables targeted (not scatter-gather) queries.

• Indexing keeps queries fast at scale: B-tree indexes avoid full collection scans; compound and covered indexes serve large-result queries efficiently.

• WiredTiger storage engine: Uses compression and a cache to hold the working set in RAM, so hot data is served from memory while the full dataset lives on disk.

• Aggregation and processing near the data: The aggregation pipeline ($match, $group) runs on the servers and pushes work down to shards, reducing data transferred.

• Replica sets for availability under load: Each shard is a replica set, giving redundancy and optional read scaling via secondary reads.

$expr lets you use aggregation expressions inside a normal query (find, $match, update filters), which most importantly enables comparing two fields of the same document to each other.

• Why it exists:

  • Standard query operators compare a field to a constant; they can't reference another field's value.

  • $expr wraps aggregation expressions so field-to-field comparisons become possible.

• Syntax difference: Inside $expr you use the aggregation forms like $gt, $eq with an array of operands, and reference fields with "$fieldName".

• Performance caveat: Comparisons between two fields generally can't use an index efficiently, so $expr queries may scan more documents.

The positional $ operator updates only the first array element matched by the query filter, whereas the all-positional $[] operator updates every element in the array.

• Positional $:

  • Refers to the first element that matched the query condition on that array.

  • Requires the array field to appear in the query filter; only one element changes.

• All-positional $[]: Applies the update to all elements, no filter match needed.

• Related: filtered positional $[<identifier>]: Updates only elements matching an arrayFilters condition, so you can target multiple specific elements.

Every document needs a unique _id; letting MongoDB auto-generate an ObjectId gives you a compact, roughly time-ordered key for free, while a custom _id lets you enforce a natural, meaningful identity but requires care.

• Automatic ObjectId:

  • 12-byte value embedding a timestamp, so inserts are monotonically increasing and index-friendly.

  • Guaranteed unique without coordination; great default when there's no natural key.

• Custom _id:

  • Use a domain value (email, SKU, composite key) to enforce uniqueness and avoid a redundant secondary unique index.

  • Enables direct lookups by natural key and can save storage.

• Trade-offs of custom keys:

  • Random or non-monotonic values (like UUIDs) scatter writes across the index, hurting insert locality.

  • The _id is immutable, so choosing a value that can change is a design mistake.

MongoDB schema patterns are reusable solutions that optimize for real access patterns rather than normalization; the goal is to minimize round-trips and keep frequently-read data together.

• Extended Reference:

  • Copy a few frequently-needed fields from a referenced document instead of joining every time.

  • Use case: an order stores the customer's name and city inline while keeping customer_id for full lookups.

• Bucket Pattern:

  • Group many small records (e.g. per-minute readings) into one document per time window.

  • Use case: IoT/time-series, reducing document count and index size.

• Computed Pattern:

  • Precompute and store aggregates (sums, averages) on write so reads are cheap.

  • Use case: a product document caching an average rating and review count.

• Subset Pattern: Embed only the most-used slice (e.g. 10 latest reviews) and keep the rest in a separate collection.

• Polymorphic Pattern: Store documents of differing shapes in one collection with a type field, when they're queried together.

• Attribute Pattern: Convert many similar/optional fields into an array of key-value pairs so a single index covers them all.

Design around the core entities (products, users, carts, orders) and their access patterns: embed data read together, reference data shared or unbounded, and denormalize hot fields to avoid joins on the read path.

• Products collection:

  • Embed variants, specs, and images; cache computed fields like average rating (Computed Pattern).

  • Use Subset Pattern for reviews: embed a few recent, keep the rest in a reviews collection.

• Users collection: Embed addresses and preferences (bounded, read with the profile); reference order history.

• Orders collection: Snapshot line items with product name and price at purchase time (Extended Reference), since order data must stay immutable even if the product later changes.

• Cart: Embed items in the user or a short-lived cart document; it's frequently updated and read as a unit.

• Inventory: Often kept separate for high-frequency atomic decrements, avoiding contention on large product docs.

For time-series data, use MongoDB's native time-series collections (5.0+), or the Bucket Pattern on a regular collection: both group measurements to cut document count, index overhead, and storage.

• Native time-series collections:

  • Declared with timeField, metaField, and a granularity; MongoDB buckets and compresses data automatically.

  • The metaField holds the source identity (e.g. sensor id) that rarely changes; the measured values change over time.

  • Supports automatic expiry via expireAfterSeconds for retention.

• Manual Bucket Pattern:

  • One document per device per window (e.g. per hour) holding an array of readings, plus precomputed min/max/sum.

  • Useful pre-5.0 or when you need custom bucket logic.

• Why it matters: Storing one document per raw reading explodes index size and count; bucketing keeps ranges contiguous and queries fast.

A one-to-squillions relationship (a parent with unbounded children, e.g. a host machine and its millions of log lines) should almost always use child-to-parent referencing: store a reference to the parent inside each child document, never an embedded array in the parent.

• Why not embed:

  • An embedded array that grows without bound will blow past the 16 MB document limit.

  • Constant growth causes document moves/fragmentation and rewrites of the whole parent on each append.

• Why not parent-refs an array either: Keeping an array of child _ids in the parent has the same unbounded-array problem.

• The pattern: child stores the parent id:

  • Each child document holds a field like host_id, and you index it.

  • Query children with db.logs.find({ host_id: X }), optionally paginated/limited.

• Optional hybrid: bucketing: Group many children into bounded "bucket" documents (e.g. one per hour) to cut document count while keeping arrays small.

MongoDB has no native tree type, so you choose a modeling pattern based on which operation must be fast: reading subtrees, finding ancestors, or moving nodes. The four common patterns are parent references, child references, array of ancestors, and materialized paths.

• Parent references:

  • Each node stores its immediate parent id.

  • Cheap to find a node's parent and to re-parent; finding all descendants needs recursion ($graphLookup).

• Child references:

  • Each node stores an array of its immediate children ids.

  • Good for rendering direct children; awkward for finding a node's path to the root.

• Array of ancestors:

  • Each node stores an ordered ancestors array plus its parent.

  • Finds all ancestors instantly and all descendants with one indexed query on ancestors; subtree moves require updating many nodes.

• Materialized paths:

  • Store the full path as a delimited string, e.g. ",Books,Programming,".

  • Subtree queries use an anchored regex (/^,Books,/) that can use an index; sorts naturally by hierarchy.

• Choosing:

  • Read-heavy subtree queries: array of ancestors or materialized paths.

  • Frequent moves / simple structure: parent references (with $graphLookup for traversal).

Time-series collections (added in 5.0) are a specialized collection type where MongoDB automatically buckets and columnar-compresses measurements internally, giving you the storage savings of a manual bucket pattern without you writing bucketing logic.

• How they work:

  • You create with timeField, an optional metaField (the series identifier, e.g. sensorId), and a granularity.

  • You insert one document per measurement; MongoDB groups them into hidden buckets behind a normal-looking collection view.

  • Data is stored column-wise and compressed, and the metaField plus time are optimized for range scans.

• vs. manual bucketing:

  • Manual: you write app logic to append readings into per-hour bucket documents and manage array sizes.

  • Native: the engine handles bucketing, compression, and bucket boundaries for you.

• Trade-offs / limits:

  • Great for append-heavy metrics; historically limited on updates/deletes of individual measurements and certain index types (improving each release).

  • Combine with a TTL-style expireAfterSeconds to auto-expire old data.

MongoDB offers several index types, each targeting a query shape or data model. You pick based on the field's structure and how it's queried.

• Single-field: Index on one field; supports equality, range, and sort on that field.

• Compound: Multiple fields in order; serves queries that filter/sort on a left-to-right prefix (ESR rule: Equality, Sort, Range).

• Multikey: Automatically created when you index an array field; indexes each array element.

• Text: For full-text search across string fields, with stemming and $text queries and relevance scoring.

• Geospatial: 2dsphere for spherical/earth geometry, 2d for flat coordinates; powers proximity and within-area queries.

• Hashed: Indexes a hash of the field; used mainly for hashed shard keys to spread writes evenly. Supports equality, not ranges.

• TTL: Single-field date index with expireAfterSeconds to auto-expire documents.

• Partial: Indexes only documents matching a partialFilterExpression, saving space when you query only a subset (e.g. active users).

• Unique: Enforces no duplicate values; combine with partial for "unique when present".

A covered query is one where all fields the query needs (both the filter and the returned fields) exist in a single index, so MongoDB answers it entirely from the index without fetching the actual documents. This is the fastest possible query path.

• Requirements to be covered:

  • All queried and returned fields must be part of the index.

  • You must exclude _id in the projection unless _id is in the index.

  • No indexed field can be an array (multikey indexes can't cover).

• How to create one: Build a compound index over the filter fields plus the projected fields, then project only those fields.

• How to confirm: explain() shows an IXSCAN with no FETCH stage and totalDocsExamined: 0.

Indexes speed reads but tax writes and consume storage/RAM, so each index should earn its place. Selectivity (how much an index narrows results) determines whether the planner will even use it effectively.

• Read benefit: Turns collection scans into targeted lookups; enables efficient sorts and covered queries.

• Write cost: Every insert/update/delete must maintain every affected index, so more indexes mean slower writes.

• Storage and memory: Indexes take disk space and ideally the working set of index entries fits in RAM; too many can evict useful data.

• Selectivity and cardinality:

  • High-cardinality fields (many distinct values, e.g. email) are highly selective and make great indexes.

  • Low-cardinality fields (e.g. a boolean or status with two values) are poorly selective; an index may scan a large fraction of docs anyway.

• Rule of thumb: Index for your actual query patterns, prefer selective fields, and drop unused indexes.

The ESR rule is the recommended ordering for fields in a compound index: put Equality fields first, then Sort fields, then Range fields. This lets one index filter precisely, return results already sorted, and scan the range efficiently.

• Equality first: Fields matched with exact values (e.g. status: "active") narrow the search to a contiguous block of index entries.

• Sort next: Placing sort fields after equality means the matching entries are already in sorted order, avoiding an in-memory sort.

• Range last: Range predicates ($gt, $lt) scan a span of entries; if placed before a sort they'd break the sort ordering.

• Why it matters: Wrong order forces a blocking in-memory sort or a wider index scan; ESR keeps the query fully index-driven.

The prefix rule says a compound index can serve any query that uses a left-to-right prefix of its fields. The planner can use the leading contiguous subset of index fields, but not fields in the middle or end without the ones before them.

• What a prefix is: For index { a: 1, b: 1, c: 1 }, the usable prefixes are {a}, {a,b}, and {a,b,c}.

• Served queries: Filters on a, or a + b, or all three use the index.

• Not served (or only partially): A query on only b, only c, or b + c skips the leading field and cannot use the index efficiently.

• Practical payoff: One well-ordered compound index can replace multiple single-field indexes, reducing write overhead.

A wildcard index automatically indexes all fields (or a subtree of fields) matching a path pattern, without naming each field ahead of time. It's designed for unpredictable or highly variable document shapes where you can't know which fields will be queried.

• How it works:

  • Created with a $** path, e.g. { "$**": 1 } or { "metadata.$**": 1 } for a subtree.

  • Can include or exclude specific paths via wildcardProjection.

• When appropriate:

  • Documents with arbitrary, user-defined, or schema-less attributes queried ad hoc.

  • Exploratory workloads where query patterns aren't yet stable.

• Limitations:

  • Not a substitute for a targeted compound index on known hot paths; a single query still uses at most one field of it in most cases.

  • Larger index and write overhead; cannot support certain multi-field/compound query needs efficiently.

Index intersection is when MongoDB uses two or more indexes to satisfy a single query, combining their results instead of relying on one compound index.

• How it works:

  • For a query with multiple conditions, MongoDB can scan two separate single-field indexes and intersect the matching document sets.

  • Shown as an AND_SORTED or AND_HASH stage in explain().

• When it's used: The optimizer chooses it when no single compound index fully covers the query but existing indexes together can.

• Limitation vs compound indexes:

  • A well-ordered compound index is usually faster and can also serve sorts; intersection rarely helps with sort ordering.

  • Rule of thumb: if a query pattern is frequent, build a dedicated compound index rather than relying on intersection.

Hinting forces MongoDB to use a specific index for a query with hint(), overriding the query planner's automatic choice.

• Why the planner might be wrong: It caches a plan based on past runs; a changed data distribution can make that plan suboptimal.

• When to force an index:

  • You've confirmed via explain() that a specific index is faster but the planner picks another.

  • To guarantee consistent, predictable performance in a critical query.

• Cautions:

  • A hint can hurt as data grows; the planner might have adapted better than your fixed choice.

  • Use hint() sparingly and re-validate periodically.

Historically a foreground build locked the database and was fast, while a background build was slower but allowed operations to continue; in MongoDB 4.2+ this distinction is gone and all index builds use a single optimized method.

• Foreground (legacy):

  • Held an exclusive lock on the database, blocking reads and writes until complete.

  • Faster and produced a more compact index.

• Background (legacy):

  • Did not hold the lock the whole time, so the collection stayed available.

  • Slower and could produce a slightly larger index.

• Modern behavior (4.2+):

  • A hybrid build takes locks only briefly at the start and end, staying non-blocking in between.

  • The background option is now ignored/deprecated.

The working set is the portion of data and indexes that your application actively accesses; keeping it in RAM is critical because disk access is orders of magnitude slower than memory.

• What it includes: Frequently queried documents plus the index entries needed to find them.

• Why RAM matters:

  • MongoDB (via the WiredTiger cache) serves in-memory pages fast; if the working set exceeds RAM, it must page from disk, causing latency spikes.

  • Indexes especially should fit in memory: every query traverses them, so index page faults slow everything.

• Symptoms of an oversized working set: High page fault rates, rising disk I/O, and degraded query latency.

• Remedies: Add RAM, shard to spread the working set across nodes, or reduce it by dropping unused indexes and trimming document size.

$facet runs multiple aggregation sub-pipelines over the same input documents in a single stage, returning all their results together: ideal for computing several views of one dataset in one pass.

• Parallel sub-pipelines: Each named facet is its own pipeline; all see the same set of input documents from the preceding stage.

• Output shape: Produces a single document whose fields are the facet names, each holding an array of that pipeline's results.

• Classic use case: Faceted search / dashboards: get paginated results, a total count, and category counts at once.

• Caveat: Sub-pipelines can't use $out, $merge, or $facet itself, and it may increase memory use.

Both write pipeline output to a collection, but $out replaces the target collection wholesale while $merge incrementally inserts/updates into an existing collection, making it far more flexible.

• $out:

  • Replaces the entire target collection (or creates it); any existing data is dropped.

  • Must be the last stage and writes to the same database (older versions).

• $merge:

  • Merges results into an existing collection with configurable behavior on match/no-match (whenMatched, whenNotMatched).

  • Can update, replace, keep, or fail on matches: enables incremental updates and on-demand materialized views.

  • Can write to any database and to a sharded collection.

• Rule of thumb: Use $out for a full rebuild; use $merge to update part of a collection or maintain rollups over time.

Each pipeline stage is limited to 100 MB of RAM by default; allowDiskUse: true lets stages that exceed this spill to temporary files on disk so the aggregation can complete instead of erroring.

• The 100 MB limit:

  • Applies per blocking stage that must hold data in memory, notably $group and $sort.

  • Exceeding it without disk use raises an error.

• allowDiskUse:

  • Permits spilling to a temporary directory on the server when the limit is hit.

  • Disk is much slower than RAM, so it's a safety valve, not a substitute for good indexes/filtering.

• Note:

  • In MongoDB 6.0+, disk use is enabled by default for many operations.

  • A $sort backed by an index can avoid the in-memory sort entirely.

Placing $match and $project early shrinks the data flowing through the pipeline as soon as possible, reducing work and memory for every downstream stage and enabling index use.

• Early $match:

  • Filters out documents before expensive stages run, so less data is processed.

  • If it's the first stage, it can use a collection index (an index scan instead of a full scan).

• Early $project: Drops unneeded fields, lowering per-document size and memory pressure in $group/$sort.

• Query optimizer: MongoDB may reorder some stages automatically (e.g. move $match before $project), but writing them early is clearer and reliable.

$graphLookup performs a recursive search within a collection, following references from document to document to traverse hierarchies or graphs (like org charts, category trees, or social connections) in a single stage.

• Recursive traversal:

  • Starts from a value and repeatedly matches connectFromField to connectToField until no more matches.

  • Collects all reachable documents into an output array field.

• Depth control: maxDepth limits recursion levels; depthField records how many hops each result is from the start.

• When to use: Finding all ancestors/descendants, transitive relationships, or reachable nodes without multiple round trips.

• Caveat: Can be expensive on large graphs; index the connectToField and bound depth to control cost.

$lookup performs a left outer join to another collection, but unlike a SQL JOIN it runs per input document and lacks the mature join optimizations of relational engines, so it can be costly at scale.

• Performance costs:

  • Conceptually executes a lookup for each incoming document, which grows with input size.

  • Without an index on the foreign field, each lookup does a collection scan: index the foreignField.

  • Embedding matched documents into an array can inflate result size and memory use.

• Compared to SQL JOIN:

  • SQL engines have decades of join optimizers (hash joins, merge joins, statistics-driven plans); $lookup is more limited.

  • It's always a left outer join style; other join types must be emulated.

• Best practices:

  • $match and reduce documents before the $lookup to minimize lookups.

  • For hot read paths, consider embedding related data to avoid the join altogether.