Domain
Database Design & Operations
A learning path that builds the ability to design and operate robust, scalable data foundations — covering SQL fundamentals, relational model theory, normalization, physical design, transactions, NoSQL/distributed databases, and operational schema evolution. Travel between logical (set theory, predicate logic) and physical (disk I/O, concurrency) spaces along the way.
The Terrain of This Field
The terrain of databases can be read as a continent you climb from the "plains of SQL" at the foot, across the plateau of theory, and up to the underground of physics and the mountains of distribution. On the first plains you shed procedural thinking and shift your footing to "thinking in sets" — the entrance everyone steps through first, the starting point of every route up.
Overlooking the plains spreads the plateau of "theory and design." On the bedrock of the relational model rest the continents of normalization, logical design, and business modeling. Only once theory truly lands do your design decisions gain a backbone; by learning the right way and the anti-patterns (the failures) as two sides of one coin, you grow the ability to capture real business domains.
Beneath the plateau run the tunnels of indexes and storage engines, and beyond them rise the mountains of distributed data systems. From B-Tree to LSM-Tree — only by understanding the internals of a single node do the highest peaks of distributed consistency become solid underfoot. The key to surveying this field is the constant travel between logical and physical space.
Follow the arrows to read in order / solid = required, dashed = recommended
Share this map
Grouping
Difficulty
Difficulty
Dependencies
Computing layout...
Books in this domain
Dependencies
Reason: Only after understanding single-node storage-engine internals do discussions of consistency, replication, and partitioning across multiple nodes become grounded. Kleppmann's 'Designing Data-Intensive Applications' is the capstone that systematizes the principles of distributed data systems, placing internals knowledge as a required prerequisite.
Reason: Understanding the internals of storage engines and replication lets you predict, from structure, what to monitor and what can break in production. 'Database Reliability Engineering' bridges that internal knowledge into operational design—capacity planning, incident response, data integrity.
Reason: After understanding the theoretical trade-offs of distributed systems in Kleppmann's 'Designing Data-Intensive Applications', step into the reality of keeping them running. Based on Google's SRE principles, 'Database Reliability Engineering' (by Laine Campbell and Charity Majors) provides concrete practices for operating distributed data infrastructure reliably in production.