Almost every "what is a DBRE" article recites the same five principles. They pull them from the same source—Laine Campbell and Charity Majors' Database Reliability Engineering, published by O'Reilly in 2017, the book that turned "DBA" into "DBRE" and declared that "today's database professionals must be engineers, not administrators. We build things." What almost none of them quote is the paragraph, a few pages into that same book, where the authors concede that most companies will never actually staff the role:
A talented DBRE is a rarer commodity than a site reliability engineer (SRE) by far. Most companies cannot afford and retain more than one or two. So, we must create the most value possible, which comes from creating self-service platforms for teams to use.
That is the whole story in three sentences. The founding text of the discipline contains its own falsification—you probably can't hire a DBRE—and, in the same breath, its own fix: build a platform, not a hire. Nine years later the first half has aged into an obvious truth and the second half is only now becoming buildable. This is a piece about the quote nobody cites.
What the DBRE Was Supposed to Be
Briefly, because this part is well-covered elsewhere: DBRE is the SRE philosophy applied to stateful systems. A stateless web server can be killed and replaced in seconds; a database node holding the only copy of a customer's data cannot, so the general SRE playbook doesn't transfer cleanly. Campbell and Majors gave the data layer its own five principles—protect the data above all else, self-service for scale so teams can provision and change databases without routing every request through a human, eliminate toil, treat databases as not special snowflakes (they memorably called databases "some of the last hold outs of pethood" in an infrastructure world that had otherwise moved to cattle), and eliminate the barriers between software and operations. That's the definition. It's table stakes. The interesting part is what happened when the market tried to hire against it.
The Role the Market Actually Produced
Start with the scarcity, because the numbers are stark. The U.S. Bureau of Labor Statistics (May 2023 OEWS) counts roughly 76,000 employed database administrators in the entire country. Against that, it counts on the order of 1.6–1.9 million software developers. The people who tend the databases are outnumbered something like twenty to one by the people building on top of them—and that's counting DBAs generally, not the rarer DBRE specialization the book says most companies can't retain more than one or two of.
Now the best case. GitLab is one of the very few organizations with a formal, public DBRE job ladder written down in its handbook—the kind of concrete artifact most companies never produce. It's a useful proof point precisely because GitLab took the role seriously enough to document it. And look at what documenting it required: the listing asks for 5+ years of experience running PostgreSQL in large production environments, and the team's entire mission is scoped to a single engine—PostgreSQL. Redis and ClickHouse at GitLab belong to other teams. The organization that wrote the DBRE job description down could only make the economics work one database deep. That's not a knock on GitLab; it's the book's prediction playing out exactly. Talent this deep is rare, so you get one or two of them, and one or two of them can realistically own one engine.
Polyglot Persistence Broke the Model Further
Here's the problem the 2017 book couldn't fully anticipate: your one hireable expert is one engine deep, but your stack is not one engine wide.
Redgate's State of the Database Landscape found that 79% of organizations ran two or more database platforms in 2024 (74% in 2025). Most companies are not single-engine shops—they're running some combination of PostgreSQL and Redis and Elasticsearch and ClickHouse and whatever the acquisition brought in. And the pain of that is exactly where you'd expect it. In the same survey, "skillset requirements and training" is the number one challenge of operating multiple platforms—cited by 38% of respondents in 2024 and jumping to 57% in 2025.
Read those two facts together and the trap is obvious. The expertise you can hire is single-engine; the stack you have to operate is polyglot. The gap between the two doesn't add up as you grow—it multiplies. Every new engine in the stack is another five-years-of-production-experience specialist you can't find, can't afford, and can't retain. Hiring your way across an N-engine stack was never going to work, and the market has spent nine years confirming it.
The Prescription Everyone Skipped
Go back to the quote. When the authors hit the scarcity problem, they did not say "recruit harder" or "raise the salary band." They said the DBRE creates value "by empowering others and guiding them, not functioning as a gatekeeper"—through self-service platforms. The role was explicitly designed to scale through software, not through headcount. That's the second half of the sentence everyone stops reading after the first half.
So why didn't the industry just do it? Because in 2017, "self-service platform" mostly meant runbooks, Terraform modules, and CI checks on migrations—the mechanical, encodable parts of the job. The genuinely hard part, the deep judgment, still lived in a human head. Which index to add. When to reindex versus reshard. Why the query planner suddenly flipped from an index scan to a sequential scan after a data shift, and what to do about it. You could automate the provisioning; you could not automate the expertise. So the prescription stalled halfway: teams built self-service plumbing and still needed the scarce specialist for every real decision. The platform the book described was buildable in parts and un-buildable in the part that mattered most.
2026: The Prescription Becomes Implementable
What changed is that the judgment layer is finally encodable. Per-engine operational expertise—the reasoning a seasoned PostgreSQL or Elasticsearch or ClickHouse operator applies to a specific cluster in a specific state—can now be captured in software that reads your actual cluster state and recommends specific actions, rather than printing a generic runbook. The missing half of the 2017 platform is showing up.
This is early, and worth being honest about the stage. In Redgate's 2024 survey, 20% of organizations had implemented AI for database management; by 2026 that figure is 44% implemented-or-considering. That's a shift in progress, not a finished transition—which is exactly why now is the moment to pay attention to it rather than a story to tell in hindsight.
One principle from the book has to survive the transition intact, though: protect the data, first and above all. That constraint dictates the shape of the tool. The right shape is recommendation-first—the software carries the encoded expertise and proposes the specific change; a human reviews it and applies it. This is precisely what Pulse does across a polyglot stack: it watches PostgreSQL alongside Elasticsearch, OpenSearch, and ClickHouse, ties root-cause analysis to the real query plans and configuration behind an incident, and hands you the specific fix to approve—the platform the book prescribed, with the "empower, don't gatekeep" and "protect the data" principles built into how it behaves rather than bolted on.
You Don't Have a Hiring Problem
If you're the team running ClickHouse and Elasticsearch and Postgres with no DBA and a growing sense that you should hire one—reframe the problem. You don't have a DBRE hiring problem. You have the exact gap Campbell and Majors described in 2017: a role too rare to staff against a stack too wide to cover, whose intended solution was never a person. The difference between then and now is that the fix they prescribed—a self-service platform that carries the operational expertise—is finally buildable, because the judgment layer that used to live only in a specialist's head can now live in software that reads your clusters and recommends the move.
So stop waiting for the unicorn hire. Adopt the platform the book told you to build nine years ago. That's the DBRE function—applied across every engine in your stack, without the headcount you were never going to find. See what Pulse surfaces about your databases and start there.
