This article is based on commentary originally published on sdtimes.com, featuring insights from Robert Reeves, co-founder and CTO of Datical, a database automation company.
The Overlooked Bottleneck in DevOps
Security often gets cited as the discipline that DevOps teams bolt on too late. But there is another critical area that routinely gets left behind: the database. While development and operations teams have invested heavily in continuous integration, automated testing, and rapid deployment pipelines for application code, database change management frequently remains a manual, slow, and error-prone process.
According to Robert Reeves, co-founder and CTO of Datical, this disconnect is not a minor inconvenience — it is a fundamental blocker to DevOps success.
“Pushing out the application is the easy part of DevOps. It is managing and automating database changes that is the real challenge.”
— Robert Reeves, Co-founder and CTO, Datical
The Velocity Gap: Moving Only as Fast as Your Slowest Team
DevOps is fundamentally about accelerating the delivery of value by aligning development, operations, and other stakeholders around a shared, automated pipeline. But that acceleration is constrained by the slowest point in the chain. When database deployments remain manual and siloed, they become that constraint.
Reeves calls this the velocity gap: application development is getting faster and more automated, but database teams are not keeping pace. Organizations pursuing DevOps find their momentum stalling because they can only ship as fast as their database change process allows — and if that process requires tickets, manual reviews, and weekend maintenance windows, the pipeline grinds to a halt.
Why Database Changes Are Fundamentally Different
Part of the reason the database has lagged behind in DevOps adoption is that database changes carry a different risk profile than application code changes. Ben Geller, Vice President of Marketing at Datical, explains the distinction clearly:
“On the application side, if the developer makes a mistake and breaks the application, they can blow away that code and start over. You can’t do that when you are updating the database. The database is always in constant motion, so you have to have a purposeful way with respect to how you get those changes made and go fast.”
— Ben Geller, VP of Marketing, Datical
Application code can often be rolled back by reverting a deployment artifact or a container image. Database schemas and the data they contain cannot simply be discarded. A dropped column or a botched migration can mean permanent data loss. This reality means that database changes require more deliberate planning, versioning, and validation — not less automation, but smarter automation.
Why Database Teams Are Brought In Too Late
A common anti-pattern is treating the database team as a gating function at the end of the release process. By the time a schema change request reaches the database administrator (DBA), the application code is already written, tested, and waiting. The DBA is handed a script with little context about why the change is needed or how it fits into the broader product.
This late engagement creates several problems:
- Lack of context: DBAs cannot assess impact without understanding the business or product rationale behind a change.
- Compressed timelines: Last-minute database changes increase the risk of mistakes.
- Friction and blame: DBAs become the perceived bottleneck, creating cultural tension between teams.
- No feedback loop: Developers do not learn how their schema decisions affect database performance, compliance, or maintainability.
Closing the Gap: Three Practical Shifts
1. Integrate DBAs Into Cross-Functional Teams
DevOps is built on the principle of cross-functional teams where all the disciplines needed to deliver and operate software work together continuously, not in handoffs. Database administrators should be part of that team from the start — participating in sprint planning, architecture reviews, and deployment discussions. When DBAs understand the product and its goals, they can contribute architectural guidance that prevents problematic schema decisions before they are written into code.
2. Build Shared Technical Literacy
DBAs do not need to become full-stack developers, but a working familiarity with version control, scripting, and the CI/CD pipeline enables much better collaboration. Similarly, developers who understand basic database concepts — indexing, query performance, migration safety — write better schemas and fewer breaking changes. Investment in cross-training pays dividends in fewer late-stage surprises.
3. Automate Database Change Management
Manual SQL scripts passed around via email or ticketing systems are incompatible with a modern CI/CD pipeline. Database change management tools allow schema changes to be version-controlled, reviewed, tested in lower environments, and promoted through the pipeline in the same way application code is. Key capabilities to look for include:
- Schema version control and migration tracking
- Automated validation and rollback scripting
- Integration with CI/CD tools such as Jenkins, GitLab CI, or GitHub Actions
- Audit trails for compliance and change review
- Environment-specific deployment rules to enforce governance without slowing delivery
Building a Culture of Shared Accountability
Beyond tools and processes, closing the DevOps-database gap requires a cultural shift. When DBAs are embedded in product teams rather than sitting in a separate operations silo, the entire team develops a shared understanding of what database changes mean — for performance, for data integrity, and for the end user. That shared understanding builds trust and replaces the adversarial dynamic that often exists between developers impatient to ship and administrators cautious about risk.
Reeves puts it bluntly:
“If you think it is a real pain to deal with security and database administrators, try ignoring them. Try just cutting them out and doing it anyway, and see what happens to your application. It is not going to be worth it.”
— Robert Reeves, Co-founder and CTO, Datical
Key Takeaways
- Database deployments are a common but underappreciated bottleneck in DevOps pipelines.
- Unlike application code, database changes cannot simply be rolled back — they require deliberate, automated change management.
- DBAs should be integrated into cross-functional teams from the beginning of the delivery lifecycle, not consulted at the end.
- Automating database change management with appropriate tooling is essential to keeping pace with CI/CD delivery cadences.
- Shared technical literacy between developers and DBAs reduces friction and improves architecture decisions.
- Excluding DBAs (or security teams) from the DevOps process does not eliminate the risk — it defers and amplifies it.