The Write Path

• The write path traced step by step through a B-tree (PostgreSQL-style) and an LSM-tree (RocksDB-style).
• The three amplifications - write, read, space - and the RUM trade-off that couples them.
• A measured comparison with a reproducible Docker harness, not hand-waved numbers.
• A workload-driven framework for choosing an engine, with four worked archetypes.
• A benchmarking protocol that avoids the common ways such tests mislead.
• Full references to the primary literature and vendor docs.

1. Preface

   Preface

   Introduces the book's premise that a database's decision to update data in place or append it elsewhere shapes nearly everything measurable about it, states that the book follows one write path through the B-tree and LSM-tree rather than surveying many systems, and explains that all benchmark figures come from the included harness rather than estimates.

2. Chapter 1

   Two Philosophies of Writing

   Lays out the update-in-place (B-tree) and out-of-place (LSM-tree) philosophies, the structure they share (sorted key-value stores, write-ahead logs, in-memory caching), and previews a comparison table of trade-offs that later chapters justify in detail.

3. Chapter 2

   Inside the B-Tree Write Path

   Walks a single UPDATE through PostgreSQL's B-tree write path - locating and latching the page, writing the WAL, deferring the dirty-page write, and checkpointing - then explains where write amplification comes from (page granularity, the WAL, full-page writes) and how settings like fillfactor and checkpoint spacing tune it.

4. Chapter 3

   Inside the LSM-Tree Write Path

   Follows a write through RocksDB's LSM-tree, where WAL append and MemTable insert are the only synchronous steps, then covers flushing to SSTables, leveled versus size-tiered compaction, and the write-stall backpressure mechanism triggered when compaction can't keep pace with ingestion.

5. Chapter 4

   The Three Amplifications

   Defines write, read, and space amplification and the RUM conjecture, then reports the book's own measured benchmark comparing Pebble (LSM) and bbolt (B-tree) at one million keys, showing the LSM-tree faster on writes and mixed workloads, the B-tree faster on reads, and that the write-amplification ranking between the two designs is regime-dependent rather than fixed.

6. Chapter 5

   Choosing an Engine

   Turns the analysis into a decision framework built around how write-dominated a workload is, what shape its reads take, and tie-breaker factors like SSD endurance, space budget, and tail latency, applying it to four representative workloads and noting that many systems reasonably run both engine types side by side.

7. Chapter 6

   Conclusion: Measure Your Own Write Path

   Restates the RUM trade-off as the book's central idea and gives a six-step protocol for benchmarking your own workload - replaying real traffic, sizing data beyond memory, running long enough to trigger compaction and checkpoints, measuring bytes-to-device, and reporting tail latency - instead of relying on published numbers.

• Backend developers who need to select a datastore for a new system
• Database administrators tuning an existing B-tree or LSM-tree deployment
• Architects who need to defend a storage-engine decision with evidence rather than opinion
• Engineers who want to reason about which engine fits a given workload instead of following rules of thumb

The book assumes a working engineer with familiarity with the general idea of a B-tree and with solid-state storage; where theory is required, it is built up from first principles.

The benchmark uses a single Go harness (in the bench/ directory, run via Docker) that drives an identical workload through two production embedded engines - Pebble, the LSM-tree behind CockroachDB, and bbolt, the copy-on-write B+-tree behind etcd - so the data structure is the only variable, with Pebble's compression disabled for a purely structural comparison. It ran on an AMD Ryzen 7 5700X (8 cores/16 threads) with roughly 11.6 GiB given to Docker Desktop 29.5.3 (Linux containers, WSL2-backed storage), inserting 1,000,000 keys (16-byte keys, 100-byte values, uniform-random order, fixed seed 42) across three phases: a batched, fsync-per-batch fill, random-read lookups, and a 50/50 mixed phase with no per-op fsync. Throughput, write amplification (device write_bytes from /proc/self/io during fill divided by logical bytes), and space amplification (on-disk size divided by live-data size) are all measured directly by the harness, not estimated; only a handful of claims - the original 1996 LSM-tree paper's observation about B-tree insert cost, WiscKey's reported 50x amplification at scale, and the RUM conjecture itself - are cited from external sources rather than measured in this run.

Every database makes one decision before any other: what happens, physically, when a row is written. The choice is whether to overwrite the data in place or to append it elsewhere and reconcile the result later. That decision propagates into most of what can be measured about the system, including write throughput, read latency, space overhead, how hard the underlying solid-state drive works, behaviour under a sudden load spike, and ultimately the cost of the hardware.