I’ve been meaning to write about the 2025 DORA report since it landed last fall. Every attempt turned into a book report, a recap of survey numbers you can read at the source, so I kept shelving it. This is the version I actually wanted to write. What I couldn’t shake was one part of it: not a survey number, but a short list of seven capabilities the report says decide whether AI makes a team better or worse. Read that list as a database engineer and four of the seven stop being DevOps advice and turn into a description of your schema.
What DORA actually measured
DORA’s 2025 State of AI-assisted Software Development report surveyed nearly 5,000 technology professionals and ran over 100 hours of qualitative interviews. Four findings from it matter here, and they are worth taking one at a time rather than as a single “AI is complicated” paragraph.
The first is an adoption-trust split. 90% of respondents reported using AI at work, and more than 80% believed it raised their productivity. In the same population, 30% reported little or no trust in the code the tools generate, slightly lower than the year before. So four in five feel faster while nearly a third don’t trust the output they’re moving faster on. Those are not contradictory answers from confused people. They are the honest description of a workflow where generation is quick and confidence in the result is a separate step somebody has to choose to spend time on.
The second finding is the one that should make a DBA sit up. Throughput went up and stability went down, in the same data. The report observes “a positive relationship between AI adoption on both software delivery throughput and product performance,” and, in the same breath, that “AI adoption does continue to have a negative relationship with software delivery stability.” More change, shipped faster, breaking more often. DORA names the mechanism directly: “AI accelerates software development, but that acceleration can expose weaknesses downstream. Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability.”
That sentence is the hinge of this whole post. Acceleration without control systems produces instability, and at the data layer the control systems are schema-side. There is a cost the report doesn’t price directly and I’ll name for the rest of this piece: the verification tax. Generating a query or a migration is cheap; confirming it does what the question asked is not, and the size of that confirmation is set almost entirely by how much the schema wrote down about itself. Ask an assistant for on-hand quantity by warehouse and it will cheerfully sum a quantity column that stores shipments as positive numbers, inflating stock that shipped out; the statement parses, runs in 60ms, and is wrong in a way only the schema reveals. On a schema with a declared foreign key, a comment on that column, and a CHECK on the movement type, catching that is a glance. On the schema most teams actually run, it’s an archaeology dig through migrations and application code, and the honest outcome is that the dig often doesn’t happen.
The verification tax is why the slowdown shows up worst on the systems people know best. METR’s July 2025 randomized trial put 16 experienced open-source developers through 246 real issues on repositories they had contributed to for years, on codebases averaging over a million lines and 22,000-plus stars. With AI tools the developers were 19% slower, even though they believed they had been sped up by about 20%. That perception gap is the DORA adoption-trust split measured on a stopwatch. Where correctness depends on deep, unwritten context, the expensive step is confirming the generated change respects it, and a mature production schema is the densest such context most teams own.
The loop is the other half of the explanation. Agentic development works by iterating: generate, run, read the failure, regenerate. Hand an agent a Bun service to port to Rust and that loop is nearly free. There is no customer data in the blast radius, the compiler and the test suite are the feedback, and a failed attempt costs a re-run. The fast feedback loops DORA lists among its control systems come built into the work. A source-of-truth system is the opposite case. A wrong UPDATE persists. A migration that mangles a column is not regenerated so much as recovered from, and iterating against production is the one thing everyone agrees an agent must not do. Staging narrows the gap, but staging data rarely has the shape, the volume, or the decade of accumulated edge cases that make prod queries wrong. The loop that makes AI genuinely good at rewrites is the loop a persistent system refuses to run, so the acceleration shows up in the codebase and the instability lands in the data.
Third is the framing DORA hangs the whole report on: AI as an amplifier. “AI doesn’t fix a team; it amplifies what’s already there. Strong teams use AI to become even better and more efficient. Struggling teams will find that AI only highlights and intensifies their existing problems.” A schema is a running record of how much of the truth a team chose to write down. AI amplifies that choice the same way it amplifies everything else. A schema that documents itself gets faster to work against. A schema that hid its meaning in tribal knowledge gets more dangerous, because now it’s queried and altered at a cadence no one is reading the schema to keep up with.
The fourth finding turns the report from a survey into a checklist. DORA published a companion AI Capabilities Model naming seven capabilities that determine whether AI adoption helps or hurts an organization. The seven, in the model’s own words: a clear and communicated AI stance, healthy data ecosystems, AI-accessible internal data, strong version control practices, working in small batches, a user-centric focus, and quality internal platforms. DORA presents these as organizational and cultural levers. Sort them by how much of each one actually lives in the database and the list splits cleanly.
Four of the seven are database problems in disguise
Healthy data ecosystems and AI-accessible internal data are, in DORA’s framing, about an organization’s data being high-quality, unified, and reachable so AI tools can give contextual help. DORA means something broad by that: analytics platforms, retrieval corpora, the pipelines that feed a model context. Narrow it to the layer where an agent writes SQL and the internal data it most needs to reach is the schema’s own self-description. A declared foreign key is the data ecosystem telling the model that stock_movements.warehouse_id resolves to warehouses.id and how many rows a join through it yields. A column comment on quantity explaining the sign convention is AI-accessible internal data in the most literal sense: the exact fact the model needed, sitting in the catalog instead of in the head of whoever built the table. When DORA says healthy data ecosystems amplify AI’s impact, at this layer that means declared constraints and commented columns. The highest-return one is still foreign keys, and the case for it stands on its own in Foreign Keys Are Not Optional; the comment side is Comment Your Schema, where published text-to-SQL work has put the accuracy gain from column descriptions in the double digits.
Working in small batches is migration discipline. DORA means small, reviewable changes in general. At the data layer a large batch is a migration that adds a column, backfills it, rewrites three query paths, and drops an index in one PR, which is exactly the shape an agent will hand you if you let it, and exactly the shape no reviewer can verify against the schema in one sitting. The batch that stays small stays checkable, and the migration that stays checkable is the one whose verification tax stays affordable.
Strong version control practices, read at the data layer, is schema versioning and the ability to roll a change back. Application code has had this for decades. A lot of production schemas still get altered by whoever has prod access and a reason. When an agent starts proposing DDL, the difference between a migration committed with a tested down-path and an ad-hoc ALTER run against prod is the difference between a change you can review and reverse and a change you can only discover after it breaks something. That is the “mature version control practices” DORA names as a control system, applied to the object the report never mentions by name.
Those four are where I’d spend the effort, because each one converts a verification cost into a fact the reviewer can read instead of reconstruct. The other three are not database-free, they’re just less database-shaped.
pg_stat_statements wired to a dashboard someone curates, a scheduled slow-query review, a schema-change review a human owns. It is the self-healing tooling you already own pointed at generated SQL. Without it, the throughput DORA measured arrives with nothing watching the stability it costs.The catalog gaps that make these queries wrong in the first place are their own subject, covered in the companion post; this one is about why the report’s stability finding lands hardest at the layer it never names.
The bigger picture
Every one of the four database capabilities has a cost that lands now against a benefit that lands later, which is exactly the accounting that got them deferred the first time. Declaring foreign keys on a long-lived schema means cleaning up the orphan rows that accumulated in their absence. Backfilling column comments is tedious metadata work with no user-visible payoff this quarter. Schema versioning and small migrations are process discipline that slows the first ten changes to speed up the next thousand. DORA measured the amplifier at the level of an organization’s delivery metrics and found the acceleration real and the instability real in the same breath. The database is where the amplifier has the most unwritten context to work with and the least automated machinery to check it. The report’s prescription for that gap, read closely, is four things you can do to your schema, and the bill for skipping them arrives every time an agent hands you a query that parses.