MongoDB
Document database with replica sets, an aggregation pipeline and optional sharding, suited to aggregate-oriented data models.
What it is
A document database storing BSON documents in collections, indexed by field path. Licensed under SSPLv1 since 2018, which is why it is absent from some Linux distributions.
Architecture
WiredTiger provides document-level concurrency, MVCC, snapshot isolation and compression. A replica
set has one primary accepting writes and secondaries applying its oplog; drivers discover topology
changes automatically and members elect a new primary when needed. Sharding adds config servers and
mongos routers.
Best use cases
- Aggregate-oriented models where a document is read and written as a unit.
- Schemas that vary between records or change frequently.
- Workloads that shard cleanly on a key present in most queries.
- Applications whose object model maps naturally onto nested documents.
When not to use it
- Highly relational data with queries joining many entities.
- Invariants spanning documents that must be enforced by the database.
- Analytical scans over huge collections.
Data model
JSON-like documents up to 16 MB, with nested objects and arrays. The size limit is a modelling constraint: unbounded arrays inside a document are a design error, not a technicality. Schema validation should be used to enforce the structure the application relies on.
Consistency and transactions
Single-document writes are atomic. Multi-document transactions exist on replica sets and sharded clusters with a 60-second default limit and real cost. Consistency is tunable per operation through read concern, write concern and read preference — where most of the durability decisions actually live.
Scaling model
Vertical, then replica sets for reads, then sharding for writes. The shard key is difficult to change, so it is the decision that deserves the most analysis.
Replication
Asynchronous oplog replication. w: "majority" prevents acknowledged writes from being rolled back;
w: 1 does not. The oplog window determines how long a secondary can be offline before needing a
full resync.
Backup and recovery
mongodump --oplog for consistent logical backups, filesystem snapshots for speed, and oplog replay
for point-in-time recovery. Sharded clusters require coordinated backups across shards and config
servers.
Monitoring
rs.status(), db.serverStatus(), db.currentOp(), the profiler, mongostat and mongotop.
See MongoDB Monitoring.
Common mistakes
Production checklist
See MongoDB Production Checklist.