SRE-based database management: what changes when reliability engineers run your data layer

I'd rather hire reliability engineers than database administrators.

That sentence annoys some people, so let me earn it.

I have enormous respect for DBAs. Some of the best engineers we've worked with carry that title. My problem isn't with the people. It's with what the traditional DBA service model asks those people to do all day: sit behind a ticket queue and react.

Two job descriptions

Imagine two people responsible for the same database.

The first one's job is: when something breaks, fix it fast. Their success is measured in response times and closed tickets. They're good at their job, so things get fixed fast. Also: the same things keep breaking, because fixing the cause was never on the ticket.

The second one's job is: make sure this class of problem stops existing. Their success is measured in issues that never escalated. When something breaks twice, that's not two incidents; that's one engineering failure, and they have the mandate and the access to go fix the system itself.

Same database. Same skills, even. Completely different outcomes over a year, because the job descriptions point in different directions.

That second job description is site reliability engineering. Google wrote it down twenty years ago for their own infrastructure, and the industry has been slowly discovering that it applies to everything with an on-call rotation, databases very much included.

What SRE looks like on a database

Words like "error budgets" and "postmortems" can sound like consultant vocabulary, so here's what actually changes day to day when reliability engineers run a data layer:

Repeat incidents become projects. 

The replication lag that fired in March fires again in May, and instead of a second fast restart, someone gets assigned to kill it: found, fixed, documented, gone. Boring by design.

Everything done twice gets automated. 

Failovers, restores, capacity checks, patching. The second time a human does it by hand, it becomes a script; the third time, it's a scheduled job with an alert on failure. Over a year, the environment quietly develops reflexes. This is exactly how the largest operators run open-source databases: Netflix manages petabyte-scale Apache Cassandra as what it calls a self-driving system, turning operational toil into control planes. Most enterprises do not need Netflix's scale, but they need the same instinct applied to their PostgreSQL, MySQL, and Cassandra.

Restores get rehearsed, not assumed. 

Backups that have never been restored are a hope, not a plan. On a schedule, an actual restore runs, gets timed, and the evidence goes to the client. The first rehearsal is always educational. That's the point of doing it before it matters.

Capacity gets planned in quarters, not discovered at 2 AM. 

Growth curves get watched, walls get seen coming, and the conversation about scaling happens in a planning meeting instead of an incident channel.

Someone brings you findings you didn't ask for. 

This one, honestly, is the tell. A team engineering your system finds things: an index that would cut a query from seconds to milliseconds, a storage tier nobody needs, a risk worth removing. A team servicing your tickets finds nothing, because nobody opened a ticket asking them to look.

"Fine, but does it matter for my business?"

Fair question.

Ticket-model economics degrade as you grow: more databases, more tickets, more cost, same recurring problems. SRE economics improve as you grow: failure classes get removed once, automation compounds, and the marginal database gets cheaper to run, not more expensive.

If your data layer is small and stable, you may never feel the difference, and honestly, the ticket model will serve you fine. If your data layer is business-critical and growing, you'll feel the difference every quarter, and on an engine like Cassandra, where unattended repair and compaction silently degrade the cluster, you'll feel it much sooner. One model is mowing the lawn. The other is landscaping.

How we run it

At Maxima Consulting, SRE isn't a service tier; it's the only way we know how to operate. Managed databases run in the client's own cloud accounts on open-source engines (PostgreSQL, MySQL, Cassandra, and more), operated 24/7/365 by follow-the-sun teams in Kraków and Pune, under a 99.99% uptime SLA enforced end to end. Every significant incident produces a root cause analysis. Every repeat is treated as our defect. If you want the fuller treatment of the discipline itself, see our complete guide to site reliability engineering.

If your current provider's monthly report is full of fast responses to the same recurring problems, you now have a name for what's missing. Schedule a discovery session.