WiredTiger Storage Engine Internals
Parent: MongoDB Performance Troubleshooting · researched 2026-05-28T18:35:25.663Z· 20 sources · 21 concepts · skill mongodb-wiredtiger-internals
WiredTiger has been MongoDB's default storage engine since 3.2 (replacing MMAPv1). It is a B-tree backed, MVCC, copy-on-write engine with document-level concurrency, configurable in-memory cache, bloc
MongoDB WiredTiger Storage Engine Internals
- WiredTiger has been MongoDB's default storage engine since 3.2 (replacing MMAPv1). It is a B-tree backed, MVCC, copy-on-write engine with document-level concurrency, configurable in-memory cache, block-level compression, and a write-ahead journal. Everything below the document model - durability, concurrency, compression, eviction, checkpoints - is WiredTiger. [source]
- This skill is the deep internals reference. For surface-level performance triage, see mongodb-performance-troubleshooting. For diagnostic packaging, see atlas-diagnostics-expert. [source]
1. Architecture Overview
- WiredTiger has a hybrid architecture optimized for multi-core CPUs and large memory: [source]
Three layers
- In-memory cache - uncompressed B-tree pages. Working set lives here. Default size: max(0.5 × (RAM − 1 GiB), 256 MiB). [source]
- Block manager - translates pages to/from disk, owns checksums, compression, encryption, free-list. [source]
- OS filesystem cache - holds compressed data blocks. Often roughly the same size as the WT cache (uncompressed) because of compression ratios. [source]
File layout under `dbPath`
- mongod exposes WiredTiger via a single WT_CONNECTION (per-process), holding one WT_CACHE struct and N WT_SESSION objects for application threads. [source]
2.1 Default sizing
- The cache size formula (since 3.4): max(0.5 × (RAM − 1 GiB), 256 MiB), capped at 10 000 GiB. [source]
- Override with one of (mutually exclusive): [source]
- Or at the command line: --wiredTigerCacheSizeGB 32 / --wiredTigerCacheSizePct 60. [source]
- Containers and cgroups: WT's default sizing was historically based on host RAM. Always pin cacheSizeGB explicitly when running in a container with a memory limit, or you will OOM. Newer MongoDB versions detect cgroup limits in some configurations, but pinning is still safest. [source]
- Sizing rule of thumb (dedicated host): target ~50% of RAM for the WT cache and leave the rest for the OS filesystem cache plus mongod overhead (connections, plan cache, TCMalloc fragmentation). On shared hosts or multi-mongod deployments, reduce proportionally per instance. [source]
2.2 What lives in the cache
- Uncompressed B-tree pages for collections and indexes that were touched recently [source]
- Dirty pages awaiting reconciliation [source]
- Update structures (per-key linked lists of in-progress modifications) [source]
- The history store (recent MVCC versions) [source]
- WT session metadata, transaction structures [source]
2.3 Two caches at once
3. Eviction (the hottest topic in production)
- Eviction reclaims cache space by either dropping clean pages or reconciling dirty pages (writing them to the data file). Done well: invisible. Done poorly: the source of 80% of WiredTiger production pain. [source]
3.1 Eviction subsystem
- One eviction server thread - walks the B-trees in fairness order, finds candidates [source]
- N eviction worker threads - pop pages from queues and actually evict them [source]
- Three queues: two ordinary + one urgent queue (priority queue) [source]
- The server samples a portion of each B-tree, scores pages by access recency, takes the one-third oldest of evictable candidates, and pushes them onto the queues. This approximates an LRU policy - true LRU would be too expensive for a multi-million-page cache. [source]
- The urgent queue holds pages flagged for forced eviction (sessions disabling eviction/splitting, large in-memory pages exceeding the maximum size, etc.). [source]
3.2 The four thresholds you must know
3.3 Application thread eviction — the smoking gun
- Normal mode: only background eviction workers do reconciliation. Pressure mode: when cache used ≥ eviction_trigger (or dirty ≥ eviction_dirty_trigger), application threads must perform eviction before they're allowed to do their own work. This shows up in serverStatus() as: [source]
- A non-zero value means writes are being throttled and latency is climbing. A persistent non-zero rate (per-second, derived from FTDC deltas) signals chronic under-sizing or under-threaded eviction. [source]
3.4 Tuning eviction at runtime
- Use wiredTigerEngineRuntimeConfig to change cache/eviction parameters without restart: [source]
- Persist in mongod.conf under setParameter: (not storage.wiredTiger): [source]
- Gotcha: forum users have reported db.adminCommand with this parameter not taking effect on certain versions - verify with db.serverStatus().wiredTiger after applying, and prefer setting it in mongod.conf for sticky deployments. [source]
3.5 Reconciliation (how dirty eviction actually works)
- When a dirty page is evicted, WT performs reconciliation: [source]
- Walk the in-memory page, collect committed values (newest visible to all readers) [source]
- Build a new on-disk image with one entry per key (newest committed value) [source]
- Push older committed versions to the history store (WiredTigerHS.wt) [source]
- If the resulting image exceeds the configured max page size, split into multiple pages [source]
- Compress, checksum, write via the block manager [source]
- If page is small enough to merge with a neighbor on the next pass, leave a hint [source]
- Reconciliation is the single most CPU-expensive operation in the engine. It's why: [source]
- Hot pages with massive update lists pin the cache [source]
- Long-running transactions inflate the history store [source]
- Cache pressure under heavy write workloads is fundamentally a reconciliation throughput problem [source]
4. Checkpoint and Journal — Two Durability Mechanisms
- WiredTiger combines checkpoints (point-in-time consistent snapshots flushed to disk) and a write-ahead log (the journal). Recovery uses both. [source]
4.1 Checkpoint
- Default interval: 60 seconds (storage.syncPeriodSecs, or via wiredTigerEngineRuntimeConfig as checkpoint=(wait=60)) [source]
- Alternative trigger: 2 GiB of journal accumulated since last checkpoint [source]
- The checkpoint thread creates a consistent snapshot of all B-trees, writes new on-disk root pointers, and only after successful write does it consider the checkpoint complete [source]
- Crash mid-checkpoint: the previous checkpoint stays valid; the new one is discarded [source]
- Storage is copy-on-write: new pages are written to free space, then the root pointer is flipped - the old pages become free list candidates after the checkpoint completes [source]
4.2 Journal (write-ahead log)
- Compressed with snappy by default. Configure via: [source]
- Files are pre-allocated 100 MB segments named WiredTigerLog.<n> under dbPath/journal/ [source]
- Records ≤ 128 bytes are not compressed (minimum log record size) [source]
- Default flush cadence: every 100 ms (group commit) - this is your data loss window in a crash [source]
- j: true write concern forces an immediate journal flush before acknowledging [source]
- disableJournal=true (NOT for replica-set members) skips the journal entirely [source]
4.3 Recovery
- Find the latest valid checkpoint in WiredTiger.wt [source]
- Replay journal records from the checkpoint LSN forward [source]
- For each table, resolve outstanding transactions (commit or roll back per stable timestamp) [source]
- Open WT_CONNECTION, expose to mongod [source]
- Worst case data loss in a clean crash (no replica set): up to 100 ms of acknowledged writes from non-j:true clients. With j:true, zero. [source]
4.4 Group commit and syncdelay
- WiredTiger batches journal flushes via group commit. --syncdelay (or storage.syncPeriodSecs) controls the checkpoint cadence, not the journal flush. Many older blog posts conflate the two - be precise: [source]
- syncPeriodSecs (default 60) → checkpoint interval [source]
- Journal flush → every 100 ms (hard-coded, plus j:true triggers) [source]
5. MVCC, Timestamps, and the History Store
- MongoDB layered timestamp-based MVCC on top of WiredTiger's transaction subsystem to support snapshot isolation, causal consistency, and readConcern: "snapshot". [source]
5.1 Snapshot isolation
- Every operation acquires a read snapshot at start. WT guarantees that the operation sees a consistent point-in-time view, regardless of concurrent writes. Readers never block writers; writers never block readers. [source]
5.2 Timestamp APIs
5.3 The history store (WiredTigerHS.wt)
- Introduced in 4.4 (replacing the old lookaside file). When reconciliation evicts a page with non-current committed versions, those older values spill into the history store. The current value stays in the data file. [source]
- History store key format: (table_id, record_id, start_timestamp, counter) - i.e., one entry per old version, per key, per timestamp. [source]
- The history store is itself a B-tree, lives in the cache, gets reconciled and evicted like any other table. Pages become reclaimable when all rows on the page are obsolete (no reader can see them, all are older than the pinned timestamp). [source]
5.4 Long-running transactions — the cardinal sin
- A snapshot pinned by a long transaction stalls cleanup: [source]
- All updates in the transaction's view must remain available → history store grows [source]
- All in-progress updates accumulate in update lists → cache pressure [source]
- Reconciliation can't compress update lists into a single value [source]
- Keep transactions short (MongoDB aborts multi-doc transactions after 60 s by default, controlled by transactionLifetimeLimitSeconds) [source]
- Set minSnapshotHistoryWindowInSeconds (default 300 s) sensibly - every second held forces history retention [source]
- Watch cache.history store on-disk size, cache.history store table updates inserted into history store, and transaction.read timestamp of the oldest active reader in FTDC [source]
- Don't run mongodump against a hot collection with a low snapshotHistoryWindow - it pins the snapshot [source]
6. Compression
- Three knobs, three layers. [source]
6.1 Block compression (collection data)
6.2 Prefix compression (indexes only)
- Indexes use prefix compression: shared key prefixes are stored once. This is on by default and almost never worth turning off - it both saves space and speeds up scans (more keys per page). [source]
6.3 Journal compression
- Records ≤ 128 bytes skip compression regardless. [source]
7. Block Manager and Page Sizing
- The block manager owns the on-disk layout. Pages are the unit of I/O. [source]
7.1 Default page sizes
- Larger pages → better compression ratio (more data per block), worse cache granularity. Smaller pages → vice versa. MongoDB ships sensible defaults; touch only with profiling evidence. [source]
7.2 In-memory page splits
- When an application thread is updating a hot page and the in-memory size crosses memory_page_max, the thread is conscripted to forcefully split the page so reconciliation doesn't see an unbounded image. This shows up as elevated cache.pages split during eviction. [source]
7.3 The free list
- When pages are written via copy-on-write, old extents become free-list candidates. The block manager tracks these for reuse. Periodic compaction (db.runCommand({ compact: "<coll>" })) consolidates free space - useful after big deletes, mostly irrelevant during steady-state operation. [source]
8. Read/Write Tickets and Concurrency
- WT enforces a hard cap on concurrent storage-engine transactions: read tickets and write tickets. [source]
8.1 Pre-7.0 behavior
- 128 read tickets, 128 write tickets, per-node, fixed [source]
- Configurable via storageEngineConcurrentReadTransactions and storageEngineConcurrentWriteTransactions [source]
- Exhaustion: new operations queue, latency climbs [source]
- db.serverStatus().wiredTiger.concurrentTransactions.{read,write}.available shows current free tickets [source]
8.2 7.0+ dynamic ticketing
- MongoDB 7.0 introduced a dynamic algorithm that adjusts ticket counts based on observed throughput and contention. Defaults are lower than 128 during normal operation - this is intentional. [source]
- Manually setting storageEngineConcurrentReadTransactions or storageEngineConcurrentWriteTransactions (or the older aliases wiredTigerConcurrentReadTransactions / wiredTigerConcurrentWriteTransactions) to a non-default value disables the dynamic algorithm on 7.0+. Don't override unless you have hard evidence of ticket starvation. Look at queue depth (queues.execution.*.in) not at available alone. [source]
8.3 Document-level locking
- WT uses optimistic concurrency control. Multiple writers can hit different documents simultaneously. Same-document concurrent writes → one wins, the other gets WT_ROLLBACK and MongoDB retries transparently. This is per-document, not per-collection - a fundamental advantage over MMAPv1's collection-level lock. [source]
9. In-Memory Storage Engine (Enterprise)
- MongoDB Enterprise ships an alternative WT configuration with no disk persistence. [source]
9.1 Configuration
- Data lives only in memory. No data files, no journal, no checkpoint. Restart = empty database. [source]
9.2 Use cases
9.3 Trade-offs
- Same MVCC, document concurrency, indexes, aggregation as on-disk WT [source]
- Sustains higher write throughput (no journal/checkpoint cost) [source]
- Can act as a replica-set secondary alongside on-disk primaries - but every secondary needs enough RAM [source]
- WT_CACHE_FULL errors are explicit and abort the operation (vs. on-disk where they'd just throttle) [source]
10. Encryption at Rest
- MongoDB Enterprise integrates encryption-at-rest at the WT block manager layer. [source]
10.1 Cipher
10.2 Key management
- Two options for the master key: [source]
- KMIP: integration with an external KMIP-compliant appliance (HashiCorp Vault Enterprise, Thales CipherTrust, Fortanix, etc.) [source]
- Default protocol version 1.2; configurable to 1.0/1.1 with security.kmip.useLegacyProtocol: true [source]
- Local keyfile: read from a file on disk (test/dev only) [source]
- The master key encrypts per-database keys (DEKs). DEKs are stored in WiredTiger.wt and encrypted with the master key. Master-key rotation re-wraps DEKs without re-encrypting data. [source]
10.3 Atlas behavior
- Atlas always uses encryption-at-rest; cloud-provider key (CMK) integration via AWS KMS, Azure Key Vault, GCP KMS is available at the cluster level - that's BYOK over the same WiredTiger layer. [source]
11.2 FTDC — the post-incident truth source
- FTDC writes to dbPath/diagnostic.data/ at ~1 Hz: hundreds of metrics, ~1 MiB/hour, < 1% CPU overhead. Every metric above is captured here as a time series. [source]
- mongo-ftdc - Grafana-fed dashboards [source]
- keyhole (Percona) - Go CLI parser, prints WT cache/eviction/checkpoint summaries [source]
- tsdiag (MongoDB internal) - bundles FTDC + logs + serverStatus for support cases [source]
- Key derived metrics to compute from FTDC deltas: [source]
- pages evicted by application threads / second → throttling rate [source]
- history store table on-disk size slope → long-txn pressure [source]
- cache.bytes currently in the cache / maximum bytes configured → cache used % [source]
- tracked dirty bytes / maximum bytes configured → dirty % [source]
11.3 Verbose component logging
11.4 wt CLI tool
- The WT distribution ships a wt command that opens a .wt file directly. Useful in disaster recovery and Percona-style forensics. Not in the mongod binary - you build it from the WT source tree. Common commands: [source]
12. Practical Tunables (the short list)
- Raw WT config string passthrough (for parameters MongoDB doesn't expose directly): [source]
13.1 Cache sizing
- Estimate working set - the set of pages touched in a typical hour. Often << total data. [source]
- Target: WT cache ≥ working set, with 20% headroom. [source]
- Leave ~50% of RAM for OS filesystem cache. [source]
- On containers, pin cacheSizeGB to a value that respects the cgroup limit. [source]
- Don't blindly set cacheSizePct: 80 - that leaves nothing for the rest of mongod (connections, plan cache, query operators, TCMalloc fragmentation) and nothing for the kernel. [source]
13.4 Switching the journal compressor to zstd
- Takes effect on next mongod restart. Pre-existing journal files keep their original compressor until they roll over (every ~100 MB or at checkpoint boundaries). [source]
15.1 "Cache full" / WT_CACHE_FULL
- Symptoms: WT_CACHE_FULL in mongod log; high latency; ops timing out. [source]
- Action ladder (cheap → expensive): [source]
- Increase eviction.threads_min/max [source]
- Lower eviction_target from 80 to 75 (start evicting sooner) [source]
- Increase cacheSizeGB if there's RAM headroom [source]
- Audit indexes - fewer indexes = fewer dirty pages on write [source]
- Audit long transactions - kill any pinning history [source]
- Move to a larger Atlas tier or instance type [source]
15.2 Persistent dirty % above 20%
- Cause: reconciliation can't keep up. Either disk write throughput is the bottleneck, or update lists are pinned by long transactions. [source]
- Increase eviction threads [source]
- Verify disk IOPS / throughput against tier [source]
- Kill long transactions or readers [source]
- Move to provisioned IOPS storage [source]
15.3 History store growing unbounded
- Symptom: WiredTigerHS.wt file size growing; cache.history store on-disk size climbing. [source]
- Cause: oldest active reader is pinned far in the past. [source]
- Action: kill the offending reader, lower minSnapshotHistoryWindowInSeconds if appropriate, audit long-running aggregations, mongodumps, and change-stream consumers. [source]
15.4 Read/write ticket starvation
- Pre-7.0 symptom: wiredTiger.concurrentTransactions.read.available → 0 sustained. [source]
- 7.0+ symptom: queues.execution.read.in > 0 sustained (queue depth, not available count). [source]
- Speed up the operations holding tickets (slow queries / locked writes) [source]
- Profile with db.currentOp({ active:true, secs_running:{$gt:1} }) [source]
- Do not raise ticket count blindly - it disables the dynamic algorithm and often makes throughput worse [source]
15.5 Slow startup / recovery
- Cause: checkpoint was old, journal is large, recovery must replay a lot. [source]
- Investigation: look at the WT recovery message at startup - it prints how many records were replayed. [source]
- Lower syncPeriodSecs to make checkpoints more frequent [source]
- Pre-warm the cache on an upgraded node before serving traffic (see mongodb-upgrade-paths cookie pre-warm SOP) [source]
15.6 Cold-cache after restart / failover
- Symptom: latency spike, query queue blowup, replica catch-up slow. [source]
- Cause: Working set has to be re-read from disk. [source]
- Pre-warm via touch/find on hot collections in a scripted warm-up [source]
- Use Atlas pre-warmed disks (newer tiers cache more of the working set) [source]
- Don't restart all nodes at once [source]
15.7 Corruption: validate, repair, and forensics
- WiredTiger pages are checksummed (CRC32C by default); the block manager will reject a torn page on read with WT_ERROR. Symptoms: corrupt WT page, checksum mismatch, WT_PANIC, or mongod refusing to start. [source]
- Triage path (in order of escalating risk): [source]
- Stop the node if it's still up - further writes can amplify damage [source]
- Run db.collection.validate({ full: true }) on a healthy replica to confirm the issue is local to the affected node [source]
- Re-sync from a healthy replica (initial sync) - the safest path for a single-node corruption in a replica set [source]
- --repair: mongod --repair --dbpath <dbPath> - last-resort rewrite that drops any unrecoverable data. Always back up dbPath/ before running. Repair does not preserve replica-set membership; the node must be re-added afterward. [source]
- wt verify: low-level forensic check on individual .wt files using the standalone WT CLI tool (built from the WT source tree) [source]
- WT_PANIC is unrecoverable in-process. The node has to be restarted; if it panics again on startup, treat it as data-file corruption and follow the path above. Never run --repair on a node still serving traffic. [source]
15.8 Index builds inflating the cache
- Background index builds (post-4.2) hold uncommitted entries in the WiredTiger cache until commit. Symptoms during a build: [source]
- Cache used % climbs and stays high [source]
- Dirty % climbs [source]
- serverStatus().wiredTiger.cache["bytes belonging to the cache overhead"] grows [source]
- Throttle with maxIndexBuildMemoryUsageMegabytes (default 200 MB per build) [source]
- Schedule large index builds in low-traffic windows [source]
- For very large collections, consider rolling index builds across replica-set members [source]
17. Related Skills
- mongodb-performance-troubleshooting - surface-level triage; this skill is the deep dive [source]
- mongodb-capacity-planning - uses WT cache sizing formulas [source]
- mongodb-monitoring-observability - FTDC parsing, Atlas metrics [source]
- atlas-diagnostics-expert - ts-diag and diagnostic packaging [source]
- mongodb-upgrade-paths - references cache pre-warm SOP (Cookie 7.0→8.0 lesson) [source]
- mongodb-transactions - multi-doc transaction layer above WT [source]
- mongodb-encryption - CSFLE/QE complement to WT encryption-at-rest [source]
- mongodb-indexes-deep - prefix compression interaction with index design [source]
- mongodb-time-series - bucket columnar layout sits on WT zstd default [source]
- mongodb-backup-restore - checkpoint/journal interaction with backup snapshots [source]
- mongodb-disaster-recovery - --repair workflow, validate(), and forensic recovery from data-file corruption [source]
18. References
- Primary documentation: [source]
- MongoDB Manual - WiredTiger Storage Engine: <https://www.mongodb.com/docs/manual/core/wiredtiger/> [source]
- MongoDB Manual v8.2 - WiredTiger Storage Engine: <https://www.mongodb.com/docs/v8.2/core/wiredtiger/> [source]
- WiredTiger Source - Eviction Architecture: <https://source.wiredtiger.com/develop/arch-eviction.html> [source]
- WiredTiger Source - Cache Architecture: <https://source.wiredtiger.com/develop/arch-cache.html> [source]
- WiredTiger Source - History Store: <https://source.wiredtiger.com/11.0.0/arch-hs.html> [source]
- WiredTiger Source - Transactions: <https://source.wiredtiger.com/develop/arch-transaction.html> [source]
- WiredTiger Source - Timestamps: <https://source.wiredtiger.com/develop/arch-timestamp.html> [source]
- WiredTiger Source - Commit-level Durability Tuning: <https://source.wiredtiger.com/develop/tune_durability.html> [source]
- WiredTiger Source - Debugging: <https://source.wiredtiger.com/develop/debugging.html> [source]
- WiredTiger Source - Cache and Eviction Tuning (6.0): <https://source.wiredtiger.com/mongodb-6.0/tune_cache.html> [source]
- MongoDB Engineering - 8.0 Performance Improvements: <https://www.mongodb.com/company/blog/mongodb-8-0-improving-performance-avoiding-regressions> [source]
- Foojay / MongoDB - Inside the Engine: 8.0 Performance Relay: <https://foojay.io/today/inside-the-engine-the-sub-millisecond-performance-relay-of-mongodb-8-0/> [source]
- Percona - WiredTiger Logging and Checkpoint Mechanism: <https://www.percona.com/blog/wiredtiger-logging-and-checkpoint-mechanism/> [source]
- Percona - Compression Methods: Snappy vs. Zstd: <https://www.percona.com/blog/compression-methods-in-mongodb-snappy-vs-zstd/> [source]
- Percona - MongoDB 101: Tuning WiredTiger Cache: <https://www.percona.com/blog/mongodb-101-how-to-tune-your-mongodb-configuration-after-upgrading-to-more-memory/> [source]
- Datadog - Monitoring WiredTiger Performance Metrics: <https://www.datadoghq.com/blog/monitoring-mongodb-performance-metrics-wiredtiger/> [source]
- Mydbops - MongoDB 7.0 Dynamic WiredTiger Tickets: <https://www.mydbops.com/blog/mongodb-7-wiredtiger-tickets> [source]
- MongoDB Dev.to - Durable History Store (WiredTigerHS.wt): <https://dev.to/mongodb/mongodb-mvcc-durable-history-store-wiredtigerhswt-mn2> [source]
- WiredTiger Wiki - Reconciliation Overview: <https://github.com/wiredtiger/wiredtiger/wiki/Reconciliation-overview> [source]
- MongoDB Repo - WT Storage Engine README: <https://github.com/mongodb/mongo/blob/master/src/mongo/db/storage/wiredtiger/README.md> [source]
Children
- Cache Architecture (frontier)
- Eviction (clean/dirty targets and triggers) (frontier)
- Application Thread Eviction (frontier)
- Reconciliation and Page Splitting (frontier)
- Checkpoint Mechanism (frontier)
- Journal (Write-Ahead Log) (frontier)
- MVCC and Snapshot Isolation (frontier)
- History Store (WiredTigerHS.wt) (frontier)
- Timestamp APIs (oldest/stable/pinned) (frontier)
- Block Compression (snappy/zlib/zstd) (frontier)
- Prefix Compression (indexes) (frontier)
- Block Manager and Page Sizing (frontier)
- Read/Write Tickets and Dynamic Concurrency (7.0+) (frontier)
- In-Memory Storage Engine (Enterprise) (frontier)
- Encryption at Rest (KMIP, AES-256-CBC/GCM) (frontier)
- Diagnostic Surface (serverStatus, FTDC, verbose components) (frontier)
- wiredTigerEngineRuntimeConfig (frontier)
- WT_CACHE_FULL / Cache Pressure Troubleshooting (frontier)
- Corruption (validate, --repair, wt CLI) (frontier)
- Long-Running Transactions and Cache Pressure (frontier)
- MongoDB 8.0 WT Improvements (TCMalloc, ExpressPlan) (frontier)
Frontier under this node: Application Thread Eviction, Block Compression (snappy/zlib/zstd), Block Manager and Page Sizing, Cache Architecture, Checkpoint Mechanism, Corruption (validate, --repair, wt CLI), Diagnostic Surface (serverStatus, FTDC, verbose components), Encryption at Rest (KMIP, AES-256-CBC/GCM), Eviction (clean/dirty targets and triggers), History Store (WiredTigerHS.wt), In-Memory Storage Engine (Enterprise), Journal (Write-Ahead Log), Long-Running Transactions and Cache Pressure, MVCC and Snapshot Isolation, MongoDB 8.0 WT Improvements (TCMalloc, ExpressPlan), Prefix Compression (indexes), Read/Write Tickets and Dynamic Concurrency (7.0+), Reconciliation and Page Splitting, Timestamp APIs (oldest/stable/pinned), WT_CACHE_FULL / Cache Pressure Troubleshooting, wiredTigerEngineRuntimeConfig