DevOps has revolutionised the way companies develop and deploy applications. Automation, CI/CD and a culture of collaboration have helped speed up development cycles and reduce the risk of software bugs. However, overshadowed by this progress is the area that still causes teams the most problems – databases.
Despite the proliferation of DevOps tools and processes , implementing changes to databases still resembles manual open-heart surgery. This is where developers and administrators most often talk about sleepless nights, stress and risk. Why is this the case and what needs to change for the database to keep up with the rest of the pipeline?
Scale of the problem
According to Redgate’s 2025 research, as many as 70 per cent of developers admit to experiencing project delays due to inconsistent database processes. Furthermore, 40 per cent are concerned that their next implementation may fail.
The consequences are not limited to the technicalities. They are real losses for the business: delayed implementations of new features, increased operational costs, and the risk of data loss. At the team level, it means additional stress, lack of trust in processes and conflicts between developers and administrators.
In short: where applications enjoy the benefits of automation and testing, databases still remain the ‘last mile’ of DevOps transformation.
Five weaknesses
The sources of problems are surprisingly similar in many organisations.
1. manual processes
Still, many changes to databases are carried out manually. Developers write scripts, adapt them to the environment and hope that no unexpected side effects occur. The lack of automatic checks means that errors only become apparent in the production environment.
2. no tests
While applications undergo comprehensive testing, databases are sometimes tested marginally. The relationships between tables, views and procedures are complex, so the slightest change can set off an avalanche of problems.
3. difficult rollbacks
In the case of applications, an error can be quickly rolled back to an earlier version. In databases, it is rarely that simple. Undoing changes to a schema or data often requires a lot of effort and sometimes risks losing information.
4 No version control
Without a version history of database objects, it is difficult to understand who made the change and when. This makes debugging as well as security audits difficult.
5. unclear responsibilities
In many organisations, the division of roles is rigid: developers modify the database, administrators ensure its stability. The lack of common processes leads to delays, tensions and faulty implementations.
Why is this so difficult?
Databases differ from applications in nature and criticality. Firstly – they store data that cannot simply be overwritten or deleted in the event of an error. Secondly – the relationships and dependencies between objects are complex and sensitive to the slightest change.
An additional challenge is the conservative approach of administrators. Since the database is a critical component, any error can mean downtime or data loss. Not surprisingly, ops prefers to rely on tried-and-tested manual methods, even if they slow down the whole process.
The lack of a uniform tool standard does not help either. While specific CI/CD practices prevail in applications, in the database world companies often use their own fragmented solutions.
Possible solutions
Despite the difficulties, there are directions to tame database implementations.
- Automation – incorporating database changes into the CI/CD pipeline rather than relying on manual scripts.
- Database testing – treating the database the same as the application, with comprehensive regression testing and dependency validation.
- Versioning – introducing a full history of changes to repositories so that every modification is tracked and replicable.
- DevOps for DB – bringing together the roles of developers and administrators, with clearly defined responsibilities and common processes.
What does this mean for the IT market?
Growing business pressures mean that companies need to shorten deployment cycles and minimise the risk of downtime. This means that databases need to keep up with the rest of the DevOps ecosystem.
This can be seen in the activities of tool providers: Redgate, Liquibase or Flyway are developing solutions that automate processes and facilitate the integration of databases into CI/CD pipelines. The trend is clear – the role of databases in DevOps will grow in the coming years, with organisations increasingly treating them not as an ‘exception’ but as an integral part of the software development cycle.
The DevOps transformation has brought speed and predictability to companies – but only partially. As long as databases remain the bottleneck, it is difficult to talk about a full revolution.
The real breakthrough will come when changes to the bases become as secure and repeatable as the applications. Only then will DevOps fulfil its promise: shorter cycles, higher quality and less stress for teams.
