This article is based on findings reported by ZDNet drawing on a Redgate Software survey of approximately 2,000 developers. Original survey data and quotes are attributed to Redgate Software and its contributors.
DevOps Is No Longer Just for Application Code
For most of its history, DevOps has been synonymous with application delivery — continuous integration pipelines, automated testing, and frequent releases of application code. Databases, by contrast, were often treated as static infrastructure: carefully managed, rarely automated, and firmly in the hands of DBAs working in isolation from development teams.
That picture is changing. According to a Redgate Software survey of roughly 2,000 developers, database changes are increasingly being managed with the same principles applied to application code: version control, automated testing, continuous delivery, and collaborative ownership.
“Databases are recognized as another code deployment which can and should be managed, tested, automated, and improved with the same robust, reliable methodologies applied to application code.”
— Kendra Little, DevOps Advocate, Redgate Software
Key Findings: Adoption Is Rising, but Unevenly
The survey paints a picture of an industry in transition. DevOps adoption for databases is clearly growing, but it remains inconsistent — particularly around foundational practices like version control.
Adoption and Deployment Frequency
- 68% of respondents are in some phase of DevOps adoption across their projects.
- 18% say they have adopted DevOps “across all projects,” up from 15% the previous year.
- 46% are performing some form of database deployment automation.
- 49% report needing to deploy database changes weekly or on-demand — up significantly from 37% in a comparable 2017 survey.
- More than 60% of managers in larger enterprises believe a full transition from traditional to automated database deployments can be achieved within a year.
The Version Control Gap
One of the more striking findings is how many teams are deploying frequently without the safety net of version control. Of those deploying database changes weekly or more often, only 47% report using version control for their database schemas and migration scripts. That means a substantial share of teams are making direct changes to production databases without a reliable audit trail or rollback mechanism — a practice that directly correlates with defects requiring hotfixes, according to the survey.
Why Databases Present Unique DevOps Challenges
Applying DevOps to databases is not simply a matter of bolting a pipeline onto an existing schema. As Kellyn Pot’Vin-Gorman, co-author of the Redgate report, explains, databases introduce a set of concerns that don’t arise with stateless application code:
“Databases, which were formerly seen as configurable repositories much like file shares, are now seen as stateful data, controlled by code. However, databases present unique challenges in using change methodology due to the very nature and value of data. In particular, data loss can put the continued existence of the company at risk. This results in database deployments requiring more care than standard change management to ensure the code that’s deployed and data quality aren’t impacted. The natural state of a database environment is growth, so as the surface area naturally spreads, the challenge of change management and releases becomes more daunting.”
— Kellyn Pot’Vin-Gorman, Report Co-Author, Redgate Software
The core challenge is statefulness. Unlike application binaries that can be replaced atomically, a database holds the organisation’s actual data. A bad migration can corrupt or destroy records that have real business value — and unlike a failed application deployment, a failed database migration may not be trivially reversible.
The Cost of Staying Siloed
The survey asked respondents to identify the biggest drawbacks of keeping database development separate from application development pipelines. The top responses were:
- Slow development and release cycles — cited by 24% of respondents.
- Inability to respond quickly to changing business requirements — cited by 21%.
- Increased risk of failed deployments or downtime — cited by 18%.
These are not abstract concerns. In a competitive environment where applications ship continuously, a database team on a quarterly release cycle becomes a bottleneck that slows the entire organisation.
Developers Own Database Work — Whether They’re Ready or Not
One clear finding is that database responsibility has shifted significantly toward developers. 78% of survey respondents say they are responsible for both application and database deployment. This reflects a broader trend in which full-stack ownership — including the data layer — is becoming the norm rather than the exception.
This shift creates both opportunity and risk. Developers who own the full stack can ship features end-to-end without waiting for handoffs, but they also need the tooling, processes, and training to handle database changes safely. The version control gap highlighted above suggests that tooling and process adoption has not fully kept pace with the expansion of responsibility.
DevOps Improves Developer–DBA Collaboration
One of the more encouraging findings is the impact DevOps adoption has on the relationship between developers and database administrators. The survey found a significant difference in collaboration depending on whether DevOps practices were in place:
- 82% of developers in DevOps settings report that they and DBAs work together as a team.
- In non-DevOps settings, that figure drops to 58%.
This is consistent with the broader DevOps principle that organisational silos — not just technical ones — are a primary source of delivery friction. When database and application teams operate in a shared pipeline with shared visibility, collaboration becomes a natural byproduct of the workflow.
Measurable Quality Benefits for Teams That Go All In
Teams that have fully embraced database DevOps practices report better outcomes than those still in transition. According to the survey:
- Respondents who reported that all or nearly all their database deployments take place with the system online also reported lower lead times for changes and lower defect rates.
- 37% of those who have adopted DevOps across all projects report that 1% or fewer of their deployments introduce code defects requiring hotfixes.
- That compares to 30% for all other groups — a meaningful gap that suggests full adoption, not partial adoption, drives quality improvements.
What DataOps Adds to the Picture
It is worth distinguishing database DevOps from the related discipline of DataOps. While database DevOps focuses on applying CI/CD and change-management practices to database schema and code changes, DataOps is broader: it applies similar automation and quality principles to the flow of data itself through an organisation — from ingestion and transformation pipelines to analytics and reporting. Both disciplines are growing, and in mature organisations they increasingly overlap.
Practical Takeaways for Engineering Teams
Based on the survey findings, teams looking to improve their database delivery practices should prioritise the following:
- Put your database schemas and migration scripts under version control. This is the minimum baseline for repeatable, auditable deployments. Given that nearly half of frequent deployers are skipping this step, it represents the single biggest gap in current practice.
- Automate database deployments as part of your CI/CD pipeline. Manual deployments are slower and more error-prone. Treating schema changes as code — validated in a pipeline before reaching production — reduces defect rates.
- Integrate DBA expertise into the development workflow. Rather than a handoff model, embed DBA knowledge into design and code review. The data shows that DevOps teams do this far more effectively than non-DevOps teams.
- Plan for zero-downtime migrations. The survey links online deployments to better lead times and lower defect rates. Techniques such as expand-contract migrations, backward-compatible schema changes, and blue-green database deployments make this achievable.
- Test database changes as rigorously as application code. This includes unit tests for stored procedures, integration tests against a representative data set, and automated rollback verification.
Conclusion
The Redgate survey is a useful data point in a broader shift: databases are no longer exempt from the engineering discipline applied to the rest of the software stack. As deployment frequency increases and developer ownership of the data layer grows, the teams that treat database changes as first-class code — versioned, tested, automated, and collaboratively owned — are already seeing measurable advantages in release quality and speed. The version control and automation gaps that remain represent both a risk for teams that haven’t closed them and an opportunity for those ready to do so.