MongoDB Fundamentals

A document mirrors how an application already thinks about an object — nested fields and arrays map directly to JSON, with no object-relational mapping layer required.

New fields can be added to some documents without an ALTER TABLE-style migration or downtime — useful for evolving products and heterogeneous data.

MongoDB has native sharding built in — distributing a collection across many servers as data and traffic grow, without bolting on an external sharding layer.

The aggregation pipeline expresses filtering, joins, grouping, and reshaping as a sequence of composable stages, all executed inside the database.

A named group of documents, roughly analogous to a SQL table — but without an enforced column schema.

A single record, stored as BSON — MongoDB's binary JSON. Documents can nest objects and arrays arbitrarily deep, up to a 16 MB document size limit.

Every document has a unique _id field, indexed automatically. If you don't supply one, MongoDB generates an ObjectId — a 12-byte value made of a 4-byte timestamp, a 5-byte per-process random value, and a 3-byte incrementing counter.

The most common case — an index on one field, such as email or created_at.

An index on multiple fields, e.g. { customer_id: 1, created_at: -1 } — field order determines which query shapes it can serve.

Automatically created when you index a field that holds an array — one index entry per array element.

Given a filter, evaluates candidate plans — collection scan vs one or more available indexes — and caches the winning plan's shape for similar future queries.

No usable index; MongoDB examines every document in the collection. Shows up in explain() output as the plan's stage.

An index is used to narrow down candidate documents before fetching them — dramatically fewer documents examined for selective queries.

Filters documents early — placing it first lets MongoDB use an index and shrinks data flowing through later stages.

Groups documents by a key and computes aggregates like $sum, $avg, $max within each group.

$sort orders the results; $project reshapes each document's fields, including renaming and computing new ones.

The only member that accepts writes. All changes are recorded in its operation log (the oplog).

Continuously replays the primary's oplog to stay in sync. Can optionally serve reads.

If the primary becomes unreachable, remaining members vote and promote the most up-to-date secondary — automatically, with no external tool required.

The field (or fields) used to distribute documents across shards. Chosen when the collection is sharded and hard to get right: changing it later means refining it (refineCollectionShardKey, MongoDB 4.4+) or resharding the collection (reshardCollection, 5.0+), both heavier operations than picking well up front. (Individual documents' shard key values can usually be updated (MongoDB 4.2+), except _id, but only through mongos and with the full shard key in the filter.)

The query router that applications actually talk to. It doesn't store data itself — it routes each operation to the right shard(s).

Store the cluster's metadata — which shard key ranges (chunks) live on which shard.

WiredTiger, the default storage engine, keeps its working set in an in-memory cache and persists changes two ways. The journal is a write-ahead log: each write is recorded there first, and by default journal records are flushed to disk about every 100 ms (or immediately when a write asks for journal acknowledgment, j: true). Checkpoints write a consistent snapshot of the data files roughly every 60 seconds. After a crash, mongod starts from the last checkpoint and replays the journal to recover writes made since — so recovery depends on what reached the durable journal; journal commit intervals describe normal synchronization behavior, not a universal maximum data-loss guarantee, and actual durability depends on write concern, journaling settings and failure conditions. With the default writeConcernMajorityJournalDefault: true, a w: majority write is not acknowledged until it has reached the journal on a majority of members (deployments with voting in-memory members differ).

Any write to one document — including updates to its embedded arrays and sub-documents — is atomic, with no transaction needed. That is the main reason MongoDB schema design favours embedding data that changes together: one document write replaces what a relational model would do with a multi-table transaction.

For operations that must span documents or collections, MongoDB offers ACID transactions: on replica sets since 4.0, and on sharded clusters since 4.2. A transaction commits atomically. Applications can configure transaction-level read concern and write concern to match their consistency and durability requirements; snapshot reads and majority-acknowledged commits are explicit choices, not unconditional behavior: readConcern: "snapshot" gives the transaction a consistent snapshot, and writeConcern: { w: "majority" } is the usual commit setting so the commit survives a primary failover (the example below sets both explicitly). If another operation modifies a document the transaction has touched, the transaction aborts with a write conflict and the application must retry (drivers label these errors TransientTransactionError; the driver's callback API, e.g. withTransaction, retries for you).