WiredTiger storage

The keystone

WiredTiger = the default engine. Each collection/index is a B-tree.

It solves the three storage problems the InnoDB way: MVCC snapshots, a journal+checkpoint for durability, a buffer-pool-like cache — and reuses space on its own.

Concurrency

Document-level concurrency (cousin of InnoDB row-level). Many clients write different docs at once.

MVCC: a point-in-time snapshot at operation start — same shape as Postgres/InnoDB snapshot reads.

Space — no VACUUM

Deleted-doc space is tracked on free lists and reused automatically. There is no VACUUM to schedule.

Catch: reused ≠ returned to OS. File shrinks only via compact or a replica resync (the VACUUM FULL analog).

Durability

Checkpoint every 60 s — a full consistent snapshot to disk = recovery point.

Journal (write-ahead log) flushed every 100 ms / on j:true / per 100 MB file.

Recover: last checkpoint + replay journal since it (redo roll-forward).

Memory & compression

WiredTiger cache = max(50% of (RAM − 1 GB), 256 MB). Internal cache uncompressed; filesystem cache compressed.

Compression on by default: snappy (collections), prefix (indexes), zstd (time-series).

Three engines, one row