MongoDB · Beginner interview

MongoDB is a NoSQL document database that stores data as flexible, JSON-like documents (BSON) in collections, instead of rows in tables with a fixed schema. Documents can have nested structures and varying fields, and related data is often embedded rather than joined. You trade SQL's rigid schema and joins for flexibility and a data model that maps naturally to objects, which suits evolving or hierarchical data.

A document is a set of key-value pairs (like a JSON object) — the basic unit of data. A collection is a group of documents, analogous to a table but without an enforced schema. BSON is the binary format MongoDB stores documents in, extending JSON with types like ObjectId, Date, and binary. Documents in a collection can differ in structure, giving schema flexibility.

Every document has a unique _id, and by default MongoDB assigns an ObjectId — a 12-byte identifier containing a timestamp, machine/process info, and a counter. It's globally unique without coordination and roughly sortable by creation time, which is why you can derive creation time from it. You can supply your own _id instead if you have a natural key.

insertOne/insertMany add documents; find/findOne read them with a query filter; updateOne/updateMany modify them using update operators; deleteOne/deleteMany remove them. Queries and updates use a document syntax — the filter is a document describing what to match. These map to create, read, update, delete.

db.users.find({ age: { $gte: 18 } });
db.users.updateOne({ _id: id }, { $set: { active: true } });

Update operators modify fields in place. $set assigns a field's value (creating it if absent); $inc atomically increments a numeric field by an amount; $push appends a value to an array field. Using operators (rather than replacing the whole document) is atomic at the document level and only touches the fields you specify.

An upsert is an update with the option { upsert: true }: if a document matches the filter it's updated, otherwise a new document is inserted from the filter plus the update. It's the atomic 'insert or update' pattern, useful for counters, idempotent writes, and maintaining derived records without a separate existence check.

Comparison: $gt/$gte/$lt/$lte for ranges, $ne for not-equal, $in/$nin for membership. Logical: $and/$or/$not. Element: $exists for presence. Plus $regex for pattern matching and operators for arrays ($all, $elemMatch). You build a filter document combining these to express the rows you want.

db.products.find({ price: { $lt: 100 }, tags: { $in: ["sale"] } });

Projection controls which fields a query returns, given as a second argument where 1 includes a field and 0 excludes it (you can't mix except for _id). Returning only needed fields reduces data transferred and can enable covered queries. For example, find(filter, { name: 1, _id: 0 }) returns just the name.

sort orders results by fields (1 ascending, -1 descending); limit caps the number returned; skip ignores the first N (used for pagination, though skip is inefficient on large offsets — range/keyset pagination is better). They chain after find. Sorting on an indexed field avoids an expensive in-memory sort.

Embed related data in the same document when it's accessed together, owned by the parent, and bounded in size — it gives single-query reads and atomic updates (e.g. an order with its line items). Reference (store an id and look up separately) when data is shared across documents, grows unbounded, or is large — to avoid duplication and document-size limits. The rule of thumb: model around your access patterns.

It fits flexible/evolving schemas, hierarchical or document-shaped data, high write throughput, and horizontal scaling with known access patterns — content, catalogs, events, user profiles. It's less ideal when you need complex multi-entity transactions and ad-hoc joins across many relations, or strong relational integrity — a relational database serves those better. Choose based on your data shape and query patterns.

Without an index, a query scans every document in the collection (a collection scan), which is slow at scale; an index (a B-tree on chosen fields) lets MongoDB find matching documents quickly. Every collection has an index on _id by default, and you add indexes on fields used in query filters and sorts. As in any database, indexes speed reads but cost storage and write overhead.