DORA for DBAs: Measuring What Matters in Database Engineering

In many organizations, the application team deploys every day while database changes wait in a ticket queue for a DBA to review. The result is a familiar pattern: developers see the DBA team as a gate, DBAs see developers as a source of risky changes, and users wait longer for features and fixes.

For years, DORA metrics have been treated as a developer and DevOps tool. Application teams use them to track how fast and safely they ship code, while the database is left out of the picture, even though it is often where releases slow down or break. It is time for DBAs to start leveraging DORA too.

DORA metrics give database engineering teams a way out of that standoff. They measure how quickly and safely changes reach production, and they apply to schema migrations, stored procedures, index changes and configuration just as well as to application code. Used well, they turn the DBA team from gatekeepers into enablers whose job is to help developers ship quickly and keep the user experience great.

What DORA measures, in database terms

DORA (DevOps Research and Assessment) is a research program, now part of Google, that surveyed thousands of teams across industries to learn what separates high performers from low performers. It settled on four core metrics. Here is what each means when the change is a database change.

One principle matters more than any number: this is about your team and your developers, not the metrics. The metrics only tell you whether your improvements are working.

Deployment frequency: ship smaller database changes, more often

Deployment frequency counts how often you change production. It is usually the best place to start, because it forces the biggest habit change: shrinking batch size.

Many DBA teams believe fewer database releases mean less risk. It works the other way. If you ship 40 schema changes in a quarterly release and performance drops, which change caused it? Nobody knows, and the team spends hours guessing. If you ship one migration at a time, a problem points straight at its cause, and the fix is quick.

Smaller batches make a bad change easy to find

Large quarterly release

1. 40 schema changesshipped together in one release
2. Performance drops
3. Which change caused it?hours spent guessing

One migration at a time

1. 1 migrationshipped on its own
2. Performance drops
3. Cause is obviousquick, targeted fix

What this looks like for a database team:

• Keep every schema change, procedure and index definition in source control (such as GitHub), deployed by a migration tool (such as Liquibase).
• Aim for one pull request, one migration. Split large changes into small, backward-compatible steps.
• On a large shared database or monolith where shipping every change alone is impractical, use release trains: deploy database changes at fixed intervals during the day, each carrying only what is ready.

The rule is simple: ship more, ship smaller.

Change lead time: find where database changes wait

Lead time runs from the moment a developer starts a change to the moment it runs in production. It measures how quickly your organization can respond to a customer bug, a new feature request or a compliance deadline. A company that takes two months to add a column will lose to one that takes two days.

The trick is to break lead time into categories and find the biggest time waste. For database changes, the usual categories are:

1. Writing the migration
2. Waiting in the DBA review queue
3. Testing, often a separate manual step
4. Waiting for a change window
5. Running the deployment

In my experience, testing and manual review are the biggest time wastes. Rather than treating them as separate gates, build them into development:

• Run migrations automatically in CI against a realistic copy of production schema and data volume.
• Add automated checks for risky patterns: missing indexes on foreign keys, table-locking ALTERs, non-sargable queries, dropped columns still in use.
• Teach developers to write database tests and safe migrations, the way testers teach developers to write automated tests.
• Reserve human DBA review for the changes the automation flags, not every change.

Find the biggest time waste, then build it into development

Where a database change's lead time goes

1. Writing the migration
2. Waiting in the DBA review queue
3. Testing, often a separate manual step
4. Waiting for a change window
5. Running the deployment

Testing and review built into development

1. Write the migration
2. CI runs itagainst a realistic copy of production
3. Automated checksrisky patterns flagged
4. Flagged?Yes: DBA reviews it
5. Deploy

Change failure rate: measure the ratio, not the count

Change failure rate is the share of deployments that fail. The first job is defining a failure for your databases, and that definition will change as your team matures. Common database failures include:

• A migration that errors out or must be rolled back
• Blocking or lock escalation that causes timeouts
• A query plan regression that slows a critical page
• A hotfix needed to correct a schema change

A common mistake is tracking the total number of failures. That rewards deploying less, which brings back large, risky batches, and when one of those fails the user impact is big. Our goal as modern DBAs is to make failures small and well understood, so a bad change is a minor event rather than an outage.

The second lever is the feedback loop. Involve developers in production, ideally running their own database deployments through the pipeline. When a change fails, the developer sees the impact first-hand, learns from it, and helps add the automated check that prevents it next time.

Measure the ratio, then close the feedback loop

Count versus ratio

DeploymentFailed deployment

Large, infrequent releases

2 failures in 4 deployments: 50% failure rate

Fewer failures to count, but each one is a big outage.

Small, frequent changes

4 failures in 40 deployments: 10% failure rate

More failures to count, but each one is small and easy to trace.

Feedback loop

1. Developer deploysthrough the pipeline
2. Change fails
3. Developer sees the impactfirst-hand
4. Adds an automated check
5. Pipeline catches it next time

Time to restore: make recovery routine

Mean time to recovery (MTTR), which DORA now calls failed deployment recovery time, measures how fast you get back to healthy after a bad change. It is one step in incident response: first you detect the problem, then you ship the fix. MTTR covers the fix.

Focusing on MTTR alone often backfires. Under pressure, teams apply quick manual hacks in production, such as an ad hoc index or a hand-edited row, that create technical debt and sometimes make the incident worse. Trust me, I've been guilty of this before and the tech debt build up is not pretty. Teams that already ship small changes through a pipeline every day recover faster, because shipping a fix is just another deployment.

Database practices that cut recovery time:

• Expand and contract migrations. Add the new column or table first, migrate code, then remove the old structure later. Every step stays backward compatible, so rolling back the application never breaks the database.
• Feature flags. Put new database-backed behavior behind a toggle. If a new query path hurts performance, switch it off in seconds instead of rolling back a schema.
• Tested rollback and restore. Write the down script with the up script, and regularly time a point-in-time restore so you know your real recovery time before an outage tells you.
• Monitoring tied to deployments. Mark each migration on your query latency and blocking dashboards so a regression points straight to its change.

Recovery is just another deployment when every step is backward compatible

Incident response

1. Bad change ships
2. Detect the problemmonitoring tied to deployments
3. Ship the fixthis is what MTTR covers
4. Healthy again

Expand and contract

1. ExpandRollback safe

   Add the new column or table alongside the old structure.

2. Migrate codeRollback safe

   Move the application to the new structure, behind a feature flag if needed.

3. ContractLater, once nothing uses the old structure

   Remove the old column or table.

Getting started: a first 90 days for DBA teams

You do not need a new platform to begin. Start where you are:

1. Put all database code in source control, including procedures, views, indexes and permissions.
2. Pick one migration tool and route every production database change through it, so deployments are recorded automatically.
3. Agree as a team, with developers, on what counts as a failed database change.
4. Capture a baseline for all four metrics, even if the first numbers come from change tickets.
5. Find the biggest time waste in your lead time and automate it first, usually testing or manual review.
6. Adopt expand and contract and feature flags for one application team, then spread what works.
7. Review the trends monthly as a team. Never use them to rank individual DBAs or developers; they measure the system, not people.

The seven steps, grouped into a first 90 days

1. FoundationSteps 1–2

   All database code in source control, and every production change routed through one migration tool.

   Deployments are recorded automatically

2. BaselineSteps 3–4

   Agree with developers on what counts as a failed change, then capture all four metrics.

   You know where you stand

3. ImproveSteps 5–6

   Automate the biggest time waste in lead time, then adopt expand and contract and feature flags with one team.

   The first metric moves

4. ReviewStep 7, monthly

   Look at the trends together as a team. Measure the system, never individuals.

It is about developers and users, not the metrics

DORA metrics are not the goal. The goal of a modern DBA team is to empower developers to ship database changes quickly and safely, so users get features faster and see fewer outages. The metrics simply tell you whether you are getting there.

The metrics measure the outcome; they are not the goal

1. DBA teamenables, not gatekeeps
2. Developersship database changes quickly and safely
3. Usersget features faster and see fewer outages
4. DORA metricsshow whether it is working

So don't chase the numbers. Focus on your team, your developers and your users, and let DORA show you how far you have come.