Who reviews your schema changes now that the DBA is gone

Ten years ago, a 30-engineer SaaS company had a DBA, or at minimum a designated senior backend engineer who owned database decisions. In 2026, most companies in that size range do not. The DBA role did not leave one piece at a time; it dissolved, with its responsibilities absorbed by different parts of the engineering organization. Four buckets of responsibility, four different absorbing roles, one bucket that nothing quite caught. That one uncaught bucket is the structural gap this essay is about.

TL;DR. Capacity and uptime moved to the managed-database provider. Backups moved to the same provider. Query performance split between the backend engineer who wrote the code and the SRE or platform team who owns instance-level health. The fourth responsibility, judgment about the data itself (what a schema means, what depends on it, whether a change is safe against production reality), landed nowhere. Now AI agents read and write the same databases, and nobody owns what they may do to it either. The gap that remains is governance and meaning, and it is structural.

The four buckets, and where each one went

Three of the four buckets found new owners cleanly. The fourth did not.

Capacity and uptime: to the managed provider

AWS RDS, Google Cloud SQL, Neon, Supabase, Crunchy, and their competitors ship failover, replication topology management, and I/O capacity as a service. The DBA used to own the pager for these. The managed service now does. A 30-engineer SaaS in 2026 does not run its own replica failover script; it pays the provider to do it. That work moved to a vendor with many customers and thus a much lower per-team cost.

This is the cleanest of the absorptions. Capacity and uptime is a bounded problem with well-understood mechanisms, and the managed providers have had ten years to productize it. The remaining edge cases at the capacity layer (unusual failure patterns, regional failover drills) are rare enough that the in-house responsibility can sit with SRE or platform without dedicating a DBA.

Backup and recovery: to the managed provider

The same providers ship continuous backup, point-in-time recovery, cross-region replicas, and snapshot-based restore. The DBA used to own the DR drill and the nightly pg_dump; the provider now ships automated snapshots with retention policies the customer configures via console. The in-house responsibility shrinks to "pick a retention and a recovery-point objective," which is a quarterly meeting rather than a weekly operational commitment.

Query performance: to backend + SRE

Query performance tuning, the responsibility that traditionally required the most craft, split. The backend engineer who shipped the endpoint owns the performance of their specific queries. The SRE or platform team owns instance-level health: aggregate latency, connection-pool saturation, buffer-cache efficiency. The former reads pg_stat_statements for their own queries. The latter reads the same view for instance-wide patterns. Both lean heavily on managed observability (pganalyze, Datadog DBM, the provider's own dashboards) to do work the 2015 DBA would have done by hand.

This split is less clean than the first two buckets. Queries cross team boundaries (one team's index helps or hurts another team's query), connection-pool behavior is sensitive to choices made across the whole application, and the physical layer affects every query simultaneously. But the split is workable because the observability layer exposes enough signal for both sides to see what they need. The DORA reports through 2024 describe organizations of this shape as common at the mid-size SaaS tier.

Schema design: to the backend engineer, with a gap

The fourth bucket is schema design, and this is where the absorption broke down. The mechanical half transferred cleanly: the backend engineer who writes the feature writes the migration, lints it, and ships it. What did not transfer is the judgment around the schema. The 2015 DBA knew what every table meant, which columns carried money or personal data, which reports and services depended on which schema, and what production actually looked like when a change landed: table sizes, lock behavior, concurrent load. When they reviewed a migration, that whole model was behind the review.

In 2026, that model has no owner. The backend engineer knows their feature's slice of the schema. The SRE knows the instance. A teammate reviews the diff for correctness with the same partial view. Nobody holds the whole picture: what the data means, how it connects, and what a given change, written by a person or increasingly by an AI agent, will do to everything that depends on it. The meaning and the production reality are in nobody's head, and they are not in the repo either.

Why the gap is structural

Three reasons the gap is not about to close on its own.

The information is not in the repo. Judging a database change requires two kinds of knowledge the PR does not carry. The first is production state: how big the table is, what currently holds locks, what concurrent writers will be affected. The second is meaning: what the table represents, which columns are sensitive, which reports, services, and now agents depend on it. The 2015 DBA carried both by being permanently assigned to the database; the 2026 backend engineer is assigned to the feature, and the feature does not pay them to know either.

The managed provider stops at the infrastructure layer. The provider's job ends at infrastructure. They will not tell you that your CREATE INDEX is missing CONCURRENTLY, and they will not tell you what users.status means or who depends on it. That is outside the contract. Meaning and governance are workflow responsibilities, not infrastructure ones.

The observability layer detects after the fact. pganalyze, Datadog DBM, and similar tools surface the cascade after it starts. Alerting on a deploy-boundary regression is the wrong loop for "this change should not have shipped" because by the time the alert fires, the change has shipped and the damage is done. The observability loop catches the symptom; the gap is about knowing what things mean and what is safe before the change arrives.

Each of the three makes the gap reproducible. A 30-engineer SaaS that wants to close it on its own has to build and maintain a live model of its schema, what it means, and what production looks like around it. That is real work, and it is not why the team raised a seed round. So the gap sits.

What this has cost, observably

The Railway post-mortems from October 28 and December 8, 2025, covered in detail in an earlier post on this blog, are two cases where the gap bit a team publicly. The April 10, 2026 post-mortem behind the 8,400x staging-gap article is another. These are the incidents that got written up. The majority of incidents of the same shape are not written up, because they were short enough to fall under the SLA threshold, because nobody outside engineering noticed, or because the team decided the incident was not worth a public post-mortem.

The base rate for a production-unsafe migration at a SaaS running continuous migrations is not zero, and the DORA 2024 report's team archetypes that cluster on high deploy frequency also tend to cluster on high incident rates when the operational support layer has not kept up. Self-reported data, but directional. The point is that the cost of the gap is measurable even without a clean DBA-extinction-caused-outages study, because the class of incidents that the gap enables is itself visible.

The market that follows from the gap

The gap is one of the reasons Datapace exists. The judgment the DBA held was never really about reviewing SQL. It was a live model of the database: what is there, what it means, how it connects, and what production looks like around it. That model has to exist somewhere before anyone, human or AI agent, can safely change the database or reason about what it contains, which is the same argument as keeping a human in the loop on database migrations. Datapace is building that model as a context layer: resolved meaning validated by the people who own the data, the workload evidence beside it, and a policy gate over what an agent may do and access. It is the same gap the self-driving database retrospective reaches from the autonomy side: the research shipped components, but the judgment layer never shipped.

Three design consequences follow from framing the gap this way.

The output is machine-usable context, not a dashboard. The surfaces where the work now happens (an agent's context window, a pull request, a chat message, a standup) are the surfaces the answer has to reach. The dashboard was a DBA's surface because the DBA spent their day in one. The backend engineer does not, and an agent cannot use one at all.

The signal is production state plus validated meaning, not workload training. A DBA's judgment in 2015 came from reading pg_stat_activity, knowing the table sizes from memory, and knowing which tables the business could not afford to break. A context layer has to carry both halves: the live operational reading, and the resolved meaning validated by the people who own the data rather than inferred and left unchecked.

The failure mode is probabilistic. A DBA sometimes waved through a change that then caused an incident. Inferred meaning and estimated risk will sometimes be wrong too. The acceptable bar is "better than undocumented tribal knowledge," not "perfect," and the honest posture is confidence levels with human validation, never certainty.

Closing note

The DBA role dissolved because the economics of engineering at a 30-engineer SaaS do not support it, and because the managed-database providers and the observability tooling absorbed most of what the DBA used to do. The one responsibility that found no home is the judgment about the data itself: what it means, how it connects, and what a change, from a person or an AI agent, will do to everything that depends on it. In 2015 a person held that model in their head. In 2026 it needs to exist as something a team and its agents can read. Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. If you want to see what that would hold for your own stack, book a call.

Frequently asked questions

Is the DBA role really gone at a 30-engineer SaaS?

Not universally. Companies with heavy analytics workloads, strict compliance, or historical Oracle or SQL Server investment often retain one. The shift is specific to the mid-size Postgres-or-MySQL-on-managed-cloud SaaS profile, where a dedicated DBA is now rare.

What about the platform-engineering trend the 2024 DORA report covers?

Platform engineering absorbed part of the capacity-and-uptime work and some observability operation. It did not absorb judgment about the data: platform engineers own the instance, not the meaning of the tables on it. The platform team provides the database; the product team provides the changes.

Why not just hire a DBA?

Some companies do. A 30-engineer team can employ a DBA if it will pay for capacity that is underused on the median day. The cost of not hiring shows up only on the days the absence produces an incident, so the decision math tilts toward waiting until an incident is painful enough.

Is this argument specific to Postgres?

The shape generalizes. MySQL, SQL Server, and MongoDB teams face the same dissolution with different absorbing roles. Postgres is the focus because the managed-Postgres ecosystem productized capacity and backups fastest, which pulled the governance gap into relief sooner.

Does a context layer replace the DBA fully?

No, and it should not claim to. A DBA did capacity forecasting, long-range schema evolution, and organizational-risk conversations that no tool touches. A context layer targets the specific loss that measurably hurts: nobody owns what the data means, how it connects, and what a change will do to it.

Sources

1. B. Beyer, C. Jones, J. Petoff, N. R. Murphy, Site Reliability Engineering, Google, 2016.
2. D. N. Blank-Edelman, Seeking SRE, O'Reilly, 2018.
3. G. Kim, J. Humble, P. Debois, J. Willis, The DevOps Handbook (2nd edition), IT Revolution, 2021.
4. DORA, Accelerate State of DevOps Report 2024.
5. DORA, 2025 State of AI-Assisted Software Development Report.
6. Datapace blog, "One CI check would have caught both of Railway's billion-row Postgres migration outages".
7. Datapace blog, "Why staging did not catch your slow migration".