Storage: TarMK, MongoMK & the datastore
Purpose: Understand where the repository physically lives and the practical differences between storage options.
Who this page is for
| Audience | Why it matters to you |
|---|
| Backend/platform engineers | Context for maintenance, backup and performance topics |
The layers
| Layer | Holds | Options |
|---|
| Node store | The content tree (nodes/properties) | TarMK (segment files on disk) or MongoMK (MongoDB) |
| Data store | Large binaries (assets) — referenced by node store | FileDataStore, S3/Azure datastore |
TarMK vs MongoMK in one table
| TarMK (default) | MongoMK |
|---|
| Storage | Append-only segment tar files, local disk | MongoDB replica set |
| Performance | Excellent read/write for single node | Network-bound; scale-out |
| Topology | One instance per repo (+ cold standby) | Multiple author instances (clustering) |
| Ops burden | Compaction (revision GC) | MongoDB fleet + oplog care |
| When | Default choice for 6.5, including most enterprises | Genuine author horizontal-scale needs (elective territory) |
Publishers are effectively always TarMK. Author clustering via MongoMK is the elective covered in Oak clustering.
Practical consequences
- Append-only TarMK means the repo grows until revision GC (compaction) reclaims space — the single most important maintenance task (maintenance).
- Binaries live once in the datastore (deduplicated by hash); deleting content doesn't delete binaries until datastore GC runs.
- Shared datastore between author+publish saves replication bandwidth for assets (binary-less replication) — common enterprise setup.
- Disk latency directly hits everything — repo on fast local storage is non-negotiable.