Who Should Own Database Change Failures? A Deep Dive into Roles, Risks, and Responsibility

Three Roles in Database Changes

In the context of database deletions and broader schema change scenarios, three participants are involved: business developers (typically backend engineers using Java, Go, or Node.js with ORMs such as MyBatis, GORM, or TypeORM), DBAs (dedicated or ad‑hoc database administrators), and the database change tool that orchestrates the operation.

Lifecycle of a Database Change

Developers submit a change ticket through the database change tool.

The tool performs automated checks, warning about table locks for column modifications and compatibility risks for table deletions.

The DBA reviews the change.

Upon approval, the change is released.

Alarms flood in; the business suspects the recent change, pulls in the DBA, and confirms the issue.

After several days of effort, the problem is fixed.

A post‑mortem (blameless or blame‑based) is conducted.

Scenario Simulation

A developer wants to change a VARCHAR column length from 20 to 100 in MySQL 8.0: ALTER TABLE person MODIFY name VARCHAR(100); The developer submits this SQL via the change tool. The DBA, aware that MySQL 8.0 does not lock tables for simple VARCHAR modifications, approves it, and executes the statement. Unexpectedly, the service crashes because MySQL 8.0 still locks the table when the new length exceeds 64 characters.

Responsibility Debate

Both sides present arguments:

Business Team Claims Primary Responsibility

The tool failed to automatically detect the lock‑risk.

The DBA, as a professional, missed the lock issue during review.

The DBA performed the actual change execution.

Expecting developers to know low‑level MySQL details is unreasonable.

DBA Team Claims Primary Responsibility

The business team should be accountable for all aspects of their service, including the database.

The problematic SQL originated from the business side without proper risk communication (e.g., peak usage windows).

The DBA failed to detect the issue, constituting a supervisory lapse.

Author’s Viewpoint

The author concludes that the business team should bear the primary responsibility, while the DBA assumes secondary responsibility. The rationale includes:

The tool’s lack of automatic detection is a systemic shortcoming, not a developer fault.

The DBA’s missed lock detection is a mistake but only a secondary fault.

Execution responsibility alone does not dictate blame; the process design that lets the DBA press the release button should not be used to shift all blame onto them.

Developers must understand the risks of using unfamiliar APIs or database features, and should provide adequate risk warnings to DBAs.

Generalization

When vertical business teams cause incidents in collaboration with horizontal platform teams, the business team should generally assume primary responsibility. This prevents an imbalance of accountability that could demotivate platform teams.

In the simulated case, developers should inform DBAs of high‑risk windows (e.g., peak traffic) before requesting a change. If DBAs ignore such warnings and the release still fails, they share secondary responsibility.

Conclusion

Assigning fault for database change failures is a contentious issue tied to bonuses, promotions, and morale. This article proposes a principle: the business team holds primary responsibility for changes they initiate, while DBAs carry secondary responsibility for oversight and execution lapses.