Berkeley DB
maang.io System Design Series
Berkeley DB is a database that runs inside your process — a library, not a server. It offers pluggable access methods (B-tree, hash, queue) and full ACID transactions via write-ahead logging and locking. Understanding it illuminates the whole category of embedded stores and sets up its LSM-based successors like RocksDB.
This deep dive comes in three parts:
- Foundations & Core Concepts — the embedded model, access methods, and environments.
- Internals — the page cache, transactions/WAL, locking, and replication, with worked numbers.
- Interview — Staff/Principal Q&A: when to embed a database and B-tree vs LSM successors.
Berkeley DB — Part 3: System Design & Interview Mastery
maang.io System Design Series
What is this?
You now know Berkeley DB from the desk cabinet down to the log sequence number. This chapter is where that knowledge earns the offer. An interviewer rarely asks "what is Berkeley DB?" outright — but the ideas inside it (embedded storage engines, write-ahead logging, B-tree vs LSM, single-master replication) are exactly the vocabulary a Staff/Principal candidate is expected to wield. BDB is the cleanest, most historically important example to reason with.
We'll do two things: see where an embedded engine like BDB fits in real designs (with diagrams), then run a mock interview — for each question, what they're really asking, a model answer, and the senior line that signals you've done this for real.
The one-line idea: interviewers use Berkeley DB to test whether you understand storage engines as building blocks — that a database is often made of a KV engine + a WAL + a cache, and that "B-tree in place vs. LSM append-only" is a deliberate cost trade you can defend, not a brand preference.
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson