This article draws on analysis originally published by DevOps Online, referencing findings from the 2018 Accelerate State of DevOps Report (DORA) and Redgate’s 2018 State of Database DevOps Survey.
The Database: DevOps’s Forgotten Bottleneck
Organisations investing heavily in CI/CD pipelines, automated testing, and cloud-native infrastructure often overlook one critical component: the database. When database changes are managed manually, reviewed out-of-band, or simply excluded from the deployment pipeline, they become a chokepoint that erodes every efficiency gain made elsewhere in the delivery process.
The 2018 Accelerate State of DevOps Report — produced by DORA (DevOps Research and Assessment) — makes this explicit. Elite-performing organisations in the report deployed code 46 times more frequently than low performers, recovered from failures 2,604 times faster, and had a 7 times lower change failure rate. Critically, their lead time from committing a change to deploying it was under one hour, compared to one to six months for the lowest-performing cohort. Excluding the database from the DevOps workflow is one of the fastest ways to land in that low-performing bracket.
The Developer–DBA Divide
Part of the problem is cultural and historical. Application developers are focused on shipping features quickly. Database administrators (DBAs) are responsible for keeping business-critical data available, consistent, and safe. These priorities have traditionally pulled in opposite directions, breeding mutual suspicion: developers worry that DBAs will block or delay releases; DBAs worry that untested schema changes will bring down production databases.
The good news is that attitudes are shifting. Redgate’s 2018 State of Database DevOps Survey found that 58% of respondents described collaboration between developers and DBAs as either good or great — a sign that the industry recognises shared goals matter more than functional silos.
So how do you build that collaboration and make the database a first-class citizen in your DevOps process? The DORA report points to four practical focus areas.
1. Ensure Consistency by Treating Database Changes Like Code
Database development today is roughly where application development was a decade ago: changes are often made manually, undocumented, and outside any formal pipeline. The solution is to apply the same discipline that transformed application delivery.
- Version control everything. Store all schema changes, stored procedures, and seed data as SQL scripts in your version control system (Git, SVN, etc.), alongside application code. This creates a single source of truth and a full audit trail.
- Apply configuration management principles. Treat the database schema as infrastructure. Define the desired state, use tooling to detect drift, and automate remediation.
- Integrate database changes into CI/CD pipelines. Run schema migrations as a pipeline stage — building, validating, and deploying them with the same gates (automated tests, peer review, approval workflows) applied to application code.
- Use dedicated database DevOps tooling. Tools such as Flyway, Liquibase, and Redgate’s SQL Change Automation are designed to automate and version database deployments in a pipeline-friendly way.
Consistency means a change applied in development travels through test, staging, and production environments in a predictable, repeatable way — with no manual steps and no surprises.
2. Use Monitoring and Observability to Learn Continuously
Visibility is a prerequisite for improvement. In a database-inclusive DevOps workflow, this means two complementary capabilities.
Monitoring
Pre-defined metrics — query latency, replication lag, connection pool saturation, deadlock rates, index usage — need to be captured and surfaced to the whole team, not just the DBA. Dashboards should be tied to business SLAs so that a spike in database response time is immediately understood in terms of end-user impact, not just raw infrastructure numbers.
Observability
The DORA report highlights observability as a distinct and newer capability. Where monitoring answers the questions you thought to ask in advance, observability lets you ask questions you did not anticipate — exploring system behaviour through logs, traces, and events to diagnose novel failure modes. The report found that organisations with both monitoring and observability in place were 1.3 times more likely to be among the top DevOps performers.
Equally important is what you do with the data. DORA found that teams running structured post-incident reviews and using the findings to drive continuous improvement were more likely to rank among elite performers. Blameless retrospectives applied to database incidents — not just application outages — accelerate learning across the whole team.
3. Build a Common, Open Culture
One of the more counterintuitive findings in the DORA report is that industry sector is not a reliable predictor of DevOps performance. High performers exist in heavily regulated industries — government, financial services, healthcare — just as much as in fast-moving retail or technology companies. The differentiator is not what business you are in, but how your organisation behaves.
Culture shapes everything. High-performing teams share several traits:
- Openness to change. They treat the current process as a starting point, not a fixed constraint.
- Psychological safety. Team members can surface problems — including database risks — without fear of blame.
- Shared ownership. No single team owns quality or reliability in isolation; everyone is accountable for the outcome.
- Continuous learning. Skills are developed across boundaries — developers learn database fundamentals; DBAs learn deployment automation.
Leadership plays a decisive role here. Building trust, granting teams meaningful autonomy, and communicating clearly why database changes are part of the shared mission — not a bureaucratic gate — are all leadership responsibilities, not technical ones.
4. Encourage Collaboration and Shared Ownership Across the Organisation
The practical expression of that culture is how developers and DBAs actually work together day to day. Several patterns have emerged in organisations that have successfully bridged the divide.
- Embed DBAs in DevOps teams. Rather than DBAs sitting in a separate team that reviews requests on a ticket-by-ticket basis, some organisations assign a DBA as an advisor to the development team around major releases. Their role shifts from gatekeeper to coach — helping developers write migration scripts that perform safely at scale, reviewing schema designs early in the sprint rather than at deployment time.
- Shared tooling and pipelines. When developers and DBAs use the same version control repositories, the same pipeline stages, and the same deployment scripts, there is a natural forcing function for conversation and shared understanding.
- Pair reviews on database changes. Pull request reviews on schema migrations that include a DBA or a developer with database expertise catch problems earlier and spread knowledge across the team.
- Database changes in sprint planning. Including database migration tasks in sprint planning — estimated, prioritised, and tracked alongside feature work — prevents them from becoming a last-minute surprise at deployment time.
Summary: The Database Is Not Optional in DevOps
The DORA findings are clear: elite DevOps performance requires the database to be part of the delivery pipeline, not an afterthought managed outside it. The four areas outlined above — consistency through version-controlled, automated database deployments; visibility through monitoring and observability; an open, learning culture; and genuine developer–DBA collaboration — provide a practical roadmap for any team looking to close the gap.
For DBAs, this shift is also an opportunity. Moving from a reactive, ticket-driven role to an embedded advisor and automation specialist is a significant career evolution — one that makes the DBA function more visible, more valued, and more directly connected to business outcomes.
Organisations that still treat developers and DBAs as separate silos will continue to find that their database is the ceiling on their DevOps ambitions. Breaking down that barrier is not just a process improvement — it is a competitive necessity.