WiredTiger, journaling & durability

This section documents the current MongoDB 8.x server line as published at the MongoDB Server Manual, which is the reference these pages are written and verified against. No specific patch version is pinned. Some capabilities (Atlas Search, Atlas Vector Search, and parts of encryption and backup) are Atlas-only — they are linked, not documented in depth.

This content was generated with the assistance of AI and should be verified against the official manual before being relied on in production, since MongoDB iterates quickly.

This section’s bibliography lists the reference material consulted while preparing these pages.

Durability is the guarantee that an acknowledged write survives a process crash or a power loss. In MongoDB it is built in layers: the WiredTiger storage engine persists data on a single node, the journal bounds how much recent work a crash can lose, and write concern plus read concern extend those guarantees across the members of a replica set.

WiredTiger storage engine

WiredTiger has been the default and, since the removal of MMAPv1, the only supported on-disk storage engine for MongoDB. Each collection and each index is stored as its own B-tree in its own file under the --dbpath directory. Its defining properties:

  • Document-level concurrency (MVCC). Writers take a lock on the individual documents they touch, not on the whole collection or database, so unrelated writes to the same collection proceed in parallel. Readers see a consistent snapshot of the data as of the moment their operation started, without blocking writers, because WiredTiger keeps multiple versions of a document in memory (multi-version concurrency control).

  • The cache. WiredTiger keeps working data and indexes in an in-heap cache, sized by default to the larger of 50% of (RAM minus 1 GB) or 256 MB. Reads are served from the cache when possible; writes modify the cached copy and are made durable by the journal and by checkpoints rather than by an immediate file write.

  • Checkpoints. Roughly every 60 seconds (or after 2 GB of journal data) WiredTiger flushes a consistent snapshot of all cached changes to the data files. A checkpoint is self-contained: on restart the engine can open the last completed checkpoint even if the process died while writing the next one.

  • Compression. Collection data is compressed with snappy by default (fast, moderate ratio); zlib and zstd trade CPU for a higher ratio. Indexes use prefix compression by default. The block compressor is set at collection-creation time.

// https://www.mongodb.com/docs/manual/core/wiredtiger/
// inspect the engine and its cache
db.serverStatus().wiredTiger.cache["bytes currently in the cache"]

// create a collection with a specific block compressor
db.createCollection("events", {
  storageEngine: { wiredTiger: { configString: "block_compressor=zstd" } }
})

The mongod cache size can be pinned in the configuration file:

# https://www.mongodb.com/docs/manual/reference/configuration-options/
storage:
  dbPath: /var/lib/mongodb
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8
    collectionConfig:
      blockCompressor: snappy
flowchart TD W[Write operation] --> C[WiredTiger cache in RAM] C -->|every write| J[(Journal / write-ahead log)] C -->|checkpoint ~60 s| D[(Data files: B-tree per collection & index)] J -->|replay on restart| D R[Read operation] --> C

Journaling: the write-ahead log

Between checkpoints, the cache holds changes that are not yet in the data files. The journal is a write-ahead log that closes that gap: before a change is considered applied, WiredTiger appends a record of it to the journal on disk. The journal is compressed with snappy and written to the journal/ subdirectory of --dbpath.

By default WiredTiger syncs the journal to disk every 100 milliseconds, and also whenever a write with j: true is waiting. A crash therefore loses at most the last ~100 ms of writes that had not yet reached a checkpoint. On restart, mongod replays every journal record written after the last checkpoint, reconstructing the exact state at the moment of the crash; this recovery is automatic and requires no operator action.

// https://www.mongodb.com/docs/manual/core/journaling/
// require this write to be on the on-disk journal of each acknowledging member before returning
db.orders.insertOne(
  { _id: 42, total: 100 },
  { writeConcern: { w: 1, j: true } }
)

Requesting j: true forces an immediate journal sync rather than waiting up to 100 ms, at the cost of added latency per write. Journaling cannot be disabled on a WiredTiger deployment.

Cluster-level durability

On a replica set, surviving a single node’s crash is not the same as surviving a failover. A write that was only on the old primary’s disk can be rolled back when a secondary that never received it is elected. Combining write concern with read concern closes that gap:

  • { w: "majority", j: true } — the write is acknowledged only once a majority of voting members have it in their journals. Such a write is in the majority-commit point and cannot be rolled back by an election.

  • readConcern: "majority" — a query returns only data that has been acknowledged by a majority of members, so it never shows a value that a rollback could later erase.

  • readConcern: "linearizable" — on a single-document read against the primary, guarantees the result reflects all writes that completed before the read began; it pairs with w: "majority" writes and can incur extra latency while the primary confirms it is still primary.

// https://www.mongodb.com/docs/manual/reference/read-concern/
db.accounts.findOne(
  { _id: "a-1" },
  { readConcern: { level: "majority" } }
)

db.runCommand({
  find: "accounts",
  filter: { _id: "a-1" },
  readConcern: { level: "linearizable" },
  maxTimeMS: 5000
})

What MongoDB does not guarantee: writes issued with w: 1 (or { j: false }) can be lost in a failover; unacknowledged writes (w: 0) can be lost with no error; reads at the default readConcern: "local" may observe writes that are later rolled back; and no configuration makes a write durable before the client receives its acknowledgement. See Replication for rollback mechanics and the majority-commit point.

Checking for corruption

The validate command scans a collection and its indexes for structural inconsistencies and, with { full: true }, checks every document against the BSON spec. Run it during maintenance windows, as it can take a shared lock:

// https://www.mongodb.com/docs/manual/reference/command/validate/
db.orders.validate({ full: true })

For an unstartable data directory, mongod --repair rebuilds broken structures from what it can read; treat it as a last resort and prefer restoring from a healthy replica set member or a backup. Routine health checks and metrics are covered in Administration & monitoring.

Other storage engines

MongoDB Enterprise offers an in-memory storage engine (--storageEngine inMemory) that keeps all data in RAM for predictable low latency and writes nothing to disk, so its data does not survive a restart and durability must come entirely from other replica set members. The legacy MMAPv1 engine was deprecated in 4.0 and removed in 4.2; WiredTiger is the only engine on current server lines.