Database Internals

What the two parts cover

Part I: Storage engines. How data is actually laid out and found on disk. B-tree variants and why they suit read-heavy workloads, file formats, pages and buffer management, recovery and write-ahead logging, concurrency control, and log-structured storage (LSM trees, SSTables, compaction) and why it suits write-heavy workloads. After this part, the difference between PostgreSQL or MySQL on one side and Cassandra or RocksDB on the other stops being a matter of labels.

Part II: Distributed systems. Failure detection, leader election, replication and consistency models, anti-entropy and dissemination, distributed transactions, and consensus algorithms such as Paxos and Raft. It reads like a distributed systems course built around the problems databases face.

The book draws on more than a hundred papers and points to open source implementations throughout, so it doubles as a guided reading list. It is endorsed by Martin Kleppmann among others.

What readers say

The book is 376 pages and averages 4.27 out of 5 from 598 ratings on Goodreads as of September 2026. Reviewers consistently single out the storage engine chapters as the best coverage of B-trees and LSM trees they have found, and value the extensive references to papers. The common criticisms are that Part II is lighter than Part I (several readers say Designing Data-Intensive Applications covers distributed systems more thoroughly), that it is dense and hard to retain without notes, and that there is little code or hands-on material.

Before you start

This is dense material. You will get much more from it if you:

• are comfortable with basic data structures (trees, hash tables) and big-O reasoning
• have used at least one relational database beyond simple queries, including indexes and transactions
• know roughly what a process, a file system and a network call are

If Designing Data-Intensive Applications is on your list, read it first. It gives the broad map; this book goes deep on the storage and consensus parts of that map.

How to get through it

• Read Part I on its own first. It is useful immediately, even if you never touch Part II.
• Read slowly and draw the structures. Sketch a B-tree split or an LSM compaction on paper; the diagrams in your head are the point.
• Connect each chapter to a real system. After the B-tree chapters, read about PostgreSQL's indexes; after LSM trees, read about RocksDB or Cassandra's write path.
• For Part II, read the Raft paper alongside the consensus chapter, and try one of the visual Raft simulations online.

Expect several weeks of steady evening reading, and a second pass for the harder chapters.

What it changes in practice

You start asking better questions: what is the write amplification of this engine, what does this isolation level actually guarantee, what happens to reads during a leader failover. That shows up in design reviews, in debugging slow queries, and in choosing a data store for a new service.

Common questions

Is it outdated, given it is from 2019? Not in any way that matters. B-trees, LSM trees, write-ahead logging and consensus change slowly. You will not find newer products described, but the foundations those products use are all here.

Should I read this or Designing Data-Intensive Applications? If you only read one, DDIA is broader and easier. Read this one second if you want real depth on storage engines.

Will it help in system design interviews? Indirectly, and powerfully. It gives you the answers to the follow-up questions, such as why a write-heavy workload suits an LSM-based store, that separate a strong design discussion from a list of component names.

Is there any code? Very little. Pair it with reading the source of a small storage engine, or build a toy key-value store with a write-ahead log and an SSTable yourself.

Best for: backend and infrastructure engineers who want to understand database behaviour from the storage layer up.