A good day for a database administrator (DBA) is a lot like a good airline flight. A lot of excitement in either situation is bad. In a perfect world, a DBA will be productive and not spending most of their time “putting out fires.” (And fires are never a good idea on a flight!)

DBAs are expected to keep their systems up and running smoothly and securely. Developers, on the other hand, must deliver new features at an ever-increasing pace. Often these features require changes to infrastructure, including database changes, which may seem like introducing chaos into otherwise stable systems.

It’s obvious that developers and DBAs have conflicting goals, but both stability of systems and quickly delivering features which bring value to the customer are critical to an organisation’s success. Traditionally, developers could just write code to fulfil a set of requirements, and then let someone else, the operations side, figure out how the code should be implemented. These changes, including changes to the database, can be bottlenecks as the DBA and other operations folks ensure that the changes are safe and there is minimal disruption. There is often poor communication between teams and lots of blame to spread around when things go wrong.

One may conclude that the developers should just slow down and stop creating all this change, but companies that don’t innovate – and quickly – will be replaced by those that do. On the other hand, customers will also move on to other suppliers when services are not available due to unplanned outages.

To solve these problems, organisations are embracing DevOps methodologies to quickly bring value to customers while maintaining stability and decreasing deployment failures. DevOps is not a prescriptive set of steps to follow, nor a framework like Agile. It’s more of a culture change that begins by building communication and trust among teams and breaking down the silos between them. It also means smaller, more frequent releases of code. Instead of a couple of large deployments with lots of changes every month, some companies have many deployments each day with a small number of changes in each.

The latest State of Database DevOps survey found that 58% of the organisations participating had already adopted DevOps across some or all projects, and 27% planned to do so in the next two years. It also found that 66% did not include the database as part of the automated build and deployment process! There are often database changes, like new tables or columns, that must be deployed along with application changes, so this can be the bottleneck that slows down the delivery of new features.

With the right tools, DBAs can include databases in source control and generate deployment scripts that can be integrated smoothly with the changes from the other teams. Dev, test, QA, and staging databases that resemble production can be created in seconds, and private information can be sanitized automatically. Automating these tedious, time consuming steps that are so important for the DevOps pipeline frees up the DBA’s time so that they can focus on the things that require their expertise like stability, performance, availability, and security.

It isn’t easy to automate database changes so that they stay in sync with application changes, but there are companies doing it and doing it well. The only way to accomplish this is for DBAs to embrace DevOps.