Basics of MongoDB

MongoDB is a document-oriented NoSQL database (currently MongoDB 8.x) that stores data as BSON (Binary JSON) documents inside collections rather than rows inside tables. Each document is a flexible set of key-value pairs, so two documents in the same collection can have different fields — there is no rigid, predefined schema to migrate when requirements change.

The main differences from a relational database:

• Data model: documents and collections instead of rows and tables. Related data is often embedded in one document rather than split across normalized tables and reassembled with JOINs (though MongoDB does support left-outer joins via $lookup in the aggregation pipeline).
• Schema: dynamic/flexible vs. fixed. You can still enforce structure with $jsonSchema validation when you want it.
• Scaling: built for horizontal scale-out via sharding and high availability via replica sets, where RDBMS traditionally scale vertically.

A common interviewer trap: "MongoDB has no transactions / isn't ACID." That's outdated — MongoDB has supported multi-document ACID transactions since 4.0 (replica sets) and 4.2 (sharded clusters), and single-document writes have always been atomic. The honest framing in 2026 is that MongoDB shines when your access patterns favor flexible, hierarchical data and scale-out, while a normalized RDBMS still fits highly relational, transaction-heavy domains — and the two camps have converged (SQL added JSON; MongoDB added joins and ACID).

MongoDB organizes data in a three-level hierarchy. The basic components are:

• Database: the top-level container that holds collections. A single MongoDB server (or cluster) can host many databases, each isolated with its own files and permissions.

• Collection: a grouping of documents, roughly analogous to a table in an RDBMS. Collections are schema-flexible by default — documents within one can have different fields — but you can attach $jsonSchema validation rules to enforce structure when you need it. Collections are created lazily (on first insert) and can be sharded for horizontal scale.

• Document: a single record, stored as BSON (Binary JSON) — a binary form of JSON that adds types like Date, ObjectId, Decimal128, and binary data. A document is a set of field-value pairs and can nest other documents and arrays. Each has an _id primary key (an auto-generated ObjectId if you don't supply one), and the max document size is 16 MB (use GridFS for larger payloads).

A useful follow-up framing: database → collection → document maps loosely to database → table → row, but the big difference is that a document can embed related data hierarchically, so one read often returns what would take several joins in SQL.

MongoDB stores data as BSON (Binary JSON) documents grouped into collections within databases. BSON is a binary-encoded superset of JSON: it keeps the familiar field-value structure but adds types JSON lacks — ObjectId, Date, Decimal128, binary data, and 32/64-bit integers — and is designed to be fast to traverse and lightweight to scan.

Each document is self-describing and can have a different shape from its neighbors (flexible schema), so structure can evolve without a migration. Every document carries an _id primary key that is unique, immutable, and indexed.

On disk, MongoDB uses the WiredTiger storage engine (the old MMAPv1 engine was removed years ago). WiredTiger provides document-level concurrency control, compression (snappy/zlib/zstd), and MVCC snapshots — which is what underpins consistent reads and multi-document transactions. Documents are capped at 16 MB; for larger files you use GridFS, which chunks the file across documents.

A common follow-up: "Is BSON just stored JSON?" No — it's binary, typed, and length-prefixed for efficient skipping during scans, which is why MongoDB can index and query nested fields directly.

The _id field is the primary key of every MongoDB document — it uniquely identifies the document within its collection. Key properties:

• Mandatory and unique: every document must have an _id, and it's backed by a unique index that MongoDB creates automatically on every collection.
• Auto-generated if omitted: if you don't supply one on insert, MongoDB generates a 12-byte ObjectId — 4-byte timestamp + 5-byte random value + 3-byte incrementing counter. That structure makes ObjectIds roughly monotonic (sortable by creation time) and unique across machines.
• Immutable: you can't change _id after insert; to "change" it you delete and re-insert.

You can also supply your own _id (a string, number, UUID, or even a sub-document) — useful when you have a natural key like an email or SKU, which avoids a second unique index.

A common follow-up/gotcha: because ObjectIds embed a timestamp, sequential inserts hit the same side of the B-tree index, which can create a write hotspot at very high insert rates. For write-heavy or sharded workloads, interviewers like to hear that you'd consider a hashed shard key or a different _id strategy to spread writes.

In MongoDB both databases and collections are created lazily — they don't physically exist until you write data into them.

To select (and implicitly create) a database in mongosh, use the use command:

use mydb

This just switches context. The database isn't persisted until it contains at least one collection with data.

A collection is created automatically the first time you insert into it:

db.mycollection.insertOne({ name: "Ada" })

You can also create one explicitly with createCollection() — useful when you need options such as schema validation, a capped collection, or time-series settings:

db.createCollection("mycollection", {
  validator: { $jsonSchema: { /* ... */ } }
})

A common follow-up/gotcha: if you run use mydb and then show dbs, you won't see mydb until you've actually written a document — interviewers ask this to confirm you understand MongoDB's lazy creation. Note we use mongosh here; the legacy mongo shell was removed in MongoDB 6.0.

The single most important MongoDB design question — interviewers want to see that you model around access patterns, not normalization. The core rule: data that is queried together should be stored together.

Embed (nest sub-documents) when:

• The relationship is one-to-one or one-to-few (e.g. a user and their addresses).
• The child data is always loaded with the parent and doesn't grow unbounded.
• You want a single atomic write (single-document operations are always atomic — no transaction needed).

Reference (store an _id and join with $lookup) when:

• The relationship is one-to-many/many-to-many or the array would grow unbounded (e.g. a blog post and its comments at scale).
• The sub-entity is large, shared across documents, or updated independently.
• You'd otherwise risk the 16MB document limit or rewriting huge arrays on every update.

// Embedded (one-to-few)
{ _id: 1, name: "Ada", addresses: [{ city: "London" }, { city: "Paris" }] }

// Referenced (one-to-many)
{ _id: 1, name: "Ada" }                       // users
{ _id: 99, userId: 1, text: "comment..." }    // comments

Follow-ups: name the classic patterns — Extended Reference (duplicate a few hot fields to avoid a join), Subset (embed the most-recent N, reference the rest), Computed, and Bucket (for time-series/IoT). The standard gotcha: avoid unbounded arrays inside a document.