What do you think?
Rate this book
Database Reliability Engineering: Designing and Operating Resilient Database Systems
The infrastructure-as-code revolution in IT is also affecting database administration. With this practical book, developers, system administrators, and junior to mid-level DBAs will learn how the modern practice of site reliability engineering applies to the craft of database architecture and operations. Authors Laine Campbell and Charity Majors provide a framework for professionals looking to join the ranks of today’s database reliability engineers (DBRE).
You’ll begin by exploring core operational concepts that DBREs need to master. Then you’ll examine a wide range of database persistence options, including how to implement key technologies to provide resilient, scalable, and performant data storage and retrieval. With a firm foundation in database reliability engineering, you’ll be ready to dive into the architecture and operations of any modern database.
This book
Service-level requirements and risk managementBuilding and evolving an architecture for operational visibilityInfrastructure engineering and infrastructure managementHow to facilitate the release management processData storage, indexing, and replicationIdentifying datastore characteristics and best use casesDatastore architectural components and data-driven architectures
You’ll begin by exploring core operational concepts that DBREs need to master. Then you’ll examine a wide range of database persistence options, including how to implement key technologies to provide resilient, scalable, and performant data storage and retrieval. With a firm foundation in database reliability engineering, you’ll be ready to dive into the architecture and operations of any modern database.
This book
Service-level requirements and risk managementBuilding and evolving an architecture for operational visibilityInfrastructure engineering and infrastructure managementHow to facilitate the release management processData storage, indexing, and replicationIdentifying datastore characteristics and best use casesDatastore architectural components and data-driven architectures
466 pages, Kindle Edition
First published October 25, 2015
96 people are currently reading
646 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 11 of 11 reviews
August 17, 2022
Why I read it: One of the few areas where I still feel rather insecure professionally is databases. So I’m always looking for ways to improve myself. Although I have to admit I bought this particular book because it is published by O’reilly and has the word ‘database’ in the title.
What I liked about it: This was probably the first engineering book I read that was written by women, one of whom even developed a technical career after leaving music and theater. I really like finding more women in engineering to look up to.
The book begins with Maslow's hierarchy of needs applied to databases. I think that was a really neat literary trick.
In most chapters there were suggestions for other books to read, to get more in depth into the topic. I bought two more books while reading this one:
- Infrastructure as Code by Kief Morris
- Systems Performance by Brendan Gregg (this one is a really big book, but I saw a suggestions to only read the beginnings of each chapter to get familiarized with the topic and dig deep in specific chapters when you’re dealing with a related problem)
My favorite chapter was ‘Infrastructure management’, which gave a brief overview of tools used for defining infrastructure as code. It was very interesting because the tools mentioned were the same as our SREs use at work. I used to know only the names of the tools but not what they do and why and this book changed that.
There were also good (and very practical) chapters about Service Level Objectives (SLOs) and monitoring. They not only explained SLOs, but gave very concrete examples on how to define them. As well as a breakdown on why you need to be careful when averaging your monitoring data. I liked this part so much that I hope to write a short blog post based on it.
Overall this book gives a good overview on how a mature (at least from technological perspective) organization operates. From things like infrastructure management, release management, observability to documentation and knowledge sharing (at least to some extent).
It is also a good resource for someone who wants to get an overview on what kind of things an SRE job entails (the title says it is database specific, but that’s mostly the second half of the book). And that was kind of an interesting coincidence. I’m a senior software engineer and sometimes I start to think about what my next career chapter should be. One option is a broader, more abstract role of Software Architect (which I read about in Fundamentals of Software Architecture). The other is going for technical depth instead of breadth. That could look like moving to a platform/ dev-tools kind of team and maybe later even a SRE team. So it was kind of cool that I got to read about both of these roles without really planning for it (as I bought this book on a whim).
What I disliked: The content of the book was very broad and very superficial. On the topics I already knew something about I didn’t really learn anything new. And on the topics I wasn’t really familiar with, I didn’t learn anything as there weren’t any explanations, only an assumption of prior knowledge. The main scenarios where I imagine this book being useful are:
- When you are new to the field of software engineering and want to get a broader perspective on how such organizations are run
- When you need to dust off your general knowledge before a job interview
- When you are preparing some introductory level presentation on databases
My main goal when picking up this book was to improve my database knowledge. Unfortunately the book didn’t do anything for it, mainly for the reason described in the above paragraph.
The authors suggested very heavy testing in some scenarios e.g.
Rule based validation that SQL is formatted correctly, number of rows potentially affected, etc.
Security tests as part of an automated test suite to check that vulnerabilities like opportunity for SQL injection are not being introduced.
Downstream tests to ensure that any data pipeline is not adversely affected by the changes applied.
I wonder how many organizations actually do something similar.
Quote:
The goal of eliminating all risks is actually a poor one. Systems without stressors do not tend to strengthen and improve over time. They end up being brittle against unknown stressors. Systems that experience stressors regularly, and thus have been designed for resiliency, will tend to handle unknown risks more gracefully (I think this one applies to humans and our comfort zone as well).
You can also read this review (maybe in a bit more user friendly format) on my blog.
What I liked about it: This was probably the first engineering book I read that was written by women, one of whom even developed a technical career after leaving music and theater. I really like finding more women in engineering to look up to.
The book begins with Maslow's hierarchy of needs applied to databases. I think that was a really neat literary trick.
In most chapters there were suggestions for other books to read, to get more in depth into the topic. I bought two more books while reading this one:
- Infrastructure as Code by Kief Morris
- Systems Performance by Brendan Gregg (this one is a really big book, but I saw a suggestions to only read the beginnings of each chapter to get familiarized with the topic and dig deep in specific chapters when you’re dealing with a related problem)
My favorite chapter was ‘Infrastructure management’, which gave a brief overview of tools used for defining infrastructure as code. It was very interesting because the tools mentioned were the same as our SREs use at work. I used to know only the names of the tools but not what they do and why and this book changed that.
There were also good (and very practical) chapters about Service Level Objectives (SLOs) and monitoring. They not only explained SLOs, but gave very concrete examples on how to define them. As well as a breakdown on why you need to be careful when averaging your monitoring data. I liked this part so much that I hope to write a short blog post based on it.
Overall this book gives a good overview on how a mature (at least from technological perspective) organization operates. From things like infrastructure management, release management, observability to documentation and knowledge sharing (at least to some extent).
It is also a good resource for someone who wants to get an overview on what kind of things an SRE job entails (the title says it is database specific, but that’s mostly the second half of the book). And that was kind of an interesting coincidence. I’m a senior software engineer and sometimes I start to think about what my next career chapter should be. One option is a broader, more abstract role of Software Architect (which I read about in Fundamentals of Software Architecture). The other is going for technical depth instead of breadth. That could look like moving to a platform/ dev-tools kind of team and maybe later even a SRE team. So it was kind of cool that I got to read about both of these roles without really planning for it (as I bought this book on a whim).
What I disliked: The content of the book was very broad and very superficial. On the topics I already knew something about I didn’t really learn anything new. And on the topics I wasn’t really familiar with, I didn’t learn anything as there weren’t any explanations, only an assumption of prior knowledge. The main scenarios where I imagine this book being useful are:
- When you are new to the field of software engineering and want to get a broader perspective on how such organizations are run
- When you need to dust off your general knowledge before a job interview
- When you are preparing some introductory level presentation on databases
My main goal when picking up this book was to improve my database knowledge. Unfortunately the book didn’t do anything for it, mainly for the reason described in the above paragraph.
The authors suggested very heavy testing in some scenarios e.g.
Rule based validation that SQL is formatted correctly, number of rows potentially affected, etc.
Security tests as part of an automated test suite to check that vulnerabilities like opportunity for SQL injection are not being introduced.
Downstream tests to ensure that any data pipeline is not adversely affected by the changes applied.
I wonder how many organizations actually do something similar.
Quote:
The goal of eliminating all risks is actually a poor one. Systems without stressors do not tend to strengthen and improve over time. They end up being brittle against unknown stressors. Systems that experience stressors regularly, and thus have been designed for resiliency, will tend to handle unknown risks more gracefully (I think this one applies to humans and our comfort zone as well).
You can also read this review (maybe in a bit more user friendly format) on my blog.
January 25, 2018
Must read for anyone working on data stores and data platforms. A perfect blueprint to build a great DBSRE team.
August 26, 2020
Must read for every Software Engineer working with databases. Running Database systems in production can be a daunting task, Charity Majors and Laine Campbell did a great job at pointing out good and bad practices.
July 20, 2018
Some great insights, recommended also for developers and other non-DBA/DBREs alike.
December 7, 2023
Database Reliability Engineering by Laine Campbell and Charity Majors stands out as a timeless guide for anyone navigating the complexities of database systems. Contrary to concerns about potential obsolescence, the book prioritizes enduring concepts over specific technologies.
The authors advocate for practices that may require substantial time to implement but prove their worth in the long run. The book's strength lies in its communication of a comprehensive mental model, guiding readers from setting expectations to risk assessment and visualization techniques.
While some technical details are presented at a high level, the authors are transparent about this limitation, emphasizing the necessity of independent exploration. This decision preserves the book's readability for a broad audience while challenging readers to delve into certain technical nuances on their own.
In summary, Database Reliability Engineering offers valuable insights into building robust systems, making it an essential read for both seasoned professionals and those new to the field. Its emphasis on enduring principles and practical guidance ensures its relevance beyond fleeting technological trends.
The authors advocate for practices that may require substantial time to implement but prove their worth in the long run. The book's strength lies in its communication of a comprehensive mental model, guiding readers from setting expectations to risk assessment and visualization techniques.
While some technical details are presented at a high level, the authors are transparent about this limitation, emphasizing the necessity of independent exploration. This decision preserves the book's readability for a broad audience while challenging readers to delve into certain technical nuances on their own.
In summary, Database Reliability Engineering offers valuable insights into building robust systems, making it an essential read for both seasoned professionals and those new to the field. Its emphasis on enduring principles and practical guidance ensures its relevance beyond fleeting technological trends.
May 8, 2023
У меня осталось очень двоякое впечатление от книги. С одной стороны я совершенно точно порекомендую ее многим коллегам особенно начальные главы касающиеся общего подхода и SLO/SLA.
Но с другой... через текст местами приходилось просто продираться. Не знаю особенность ли это перевода или самой книги.
Но с другой... через текст местами приходилось просто продираться. Не знаю особенность ли это перевода или самой книги.
February 26, 2023
Makes many good points on the management of Databases within tech organisations, and would be worth a read for those interested in databases or who want to put in better practices around database management at their current organisation.
July 15, 2018
An excellent overview of the pointier parts of operations and possibility one of the best introductions on the topic. An easy read, with coherent and practical advice.
July 29, 2018
I've only read a selection of chapters most relevant to me. While the breadth of those chapters is very complete, a few practical examples (e.g. versioning, ...) would add more depth to the content.
January 13, 2025
read it for my "google database engineering"
Read
August 30, 2025couldn’t finish it. just lost interest honestly
Displaying 1 - 11 of 11 reviews