DBA Considered Harmful

Database administrators are often important parts of our organizations. They take care of databases, keep an eye on performance, and step in when we need to fix issues. However, what if I told you that they are harmful and we should change how they work and how they fit our organizations? Read on to understand why.

DBAs Build Siloes

One of the issues with having a separate team of DBAs is that they naturally push other teams into siloes. Let’s see why that happens.

DBAs need to understand what’s going on in the databases. To achieve that, they need to be aware of every change that goes to the database, every modification, and every system restart. This collides with how developers want to deploy their software. Developers want to push things to the repository and forget about other steps. CI/CD should take care of running all the tests, migrations, and deployments, and verifying all is correct. The pipeline may take hours to complete and developers don’t want to be bothered about that.

Unfortunately, such a model doesn’t work well with how DBAs want to operate. DBAs want to be aware of the changes and when they flow into the system. This often leads to synchronization between the teams as DBAs must be involved in the deployment process. However, once they are involved, they take control and developers feel like they don’t want to be responsible anymore.

This leads to siloing teams. Developers don’t feel responsible, DBAs need to take control, and after some time developers just push responsibilities onto DBAs. Whenever there is a change in the database needed, developers know that they must sync with DBAs anyway, so they just expect DBAs to do it. This is a vicious circle in which developers feel less and less involved which pushes DBAs to take more responsibility (because developers are not up to the task) and after some time we end up in a status quo in which developers do even less.

However, this is harmful for everyone. Developers don’t feel responsible which makes them less involved and engaged. DBAs get frustrated because they must do more. Whole organizations waste time and money.

Developers Don’t Learn

Another aspect of having DBAs around is that developers stop learning. The best way to learn is by doing things. The hands-on experience lets teams make the biggest progress in the shortest time.

Once we have DBAs around, developers can always ask DBAs for help. It’s okay if they learn in this process, but more often than not they simply push the responsibilities to other teams. Effectively, developers stop learning and databases become more and more terra incognita.

Instead, we should push developers to understand more and have hands-on experience with databases. To achieve that, developers need to do things and be the ones who maintain and operate the databases. This is hard to achieve when there is a separate team of DBAs responsible and accountable for dealing with database systems.

Organizations Waste Time on Communication

Once we have DBAs that are accountable and developers that drift towards less and less responsibility, organizations waste more and more time. Every process requires involving two teams. Since team cooperation is not something we can automate with CI/CD, we need to conduct more and more meetings and open formal communication via tickets or issues.

This degrades performance significantly. Every single time teams need to comment on issues, they waste minutes (if not hours) explaining the work instead of doing it. Even worse, they need to wait for the other side to reply and are blocked for hours. Add time zones to the picture and we can easily see how days of work are wasted.

We Need Database Guardrails

All these things can be easily solved with database guardrails. These tools integrate with developers’ environments and assess the database performance right when developers write the code. This significantly minimizes the risk of performance degradation, data loss, or other issues with the production database after the deployment.

Next, database guardrails can automate most of the DBAs’ tasks. They can tune indexes, analyze schemas, detect anomalies, and even use AI to submit code fixes automatically. This makes DBAs much less occupied with the day-to-day maintenance. Once DBAs don’t need to control every single part of the database, they don’t need to be involved in CI/CD. Developers can automate their deployments once again. Similarly, there is no need to ask DBAs for help with every single thing, as database guardrails can reason about the performance. This reduces communication even more and unblocks the teams.

Should We Get Rid of DBAs?

No, we shouldn’t. DBAs have tremendous knowledge and hands-on experience that lets them solve the most intricate issues. Once we have database guardrails in place, we can let DBAs focus on architecture, the big picture, and the long-term direction of organizations. 

Database guardrails are not going to make DBAs unemployed. They will make DBAs shine and bring organizations to the next level. No more tedious day-to-day maintenance.

Summary

The classic approach for DBAs makes organizations waste time. Teams are siloed, communicate too much, and waste time waiting for answers. Developers don’t feel responsible and they don’t learn. DBAs are swamped with day-to-day tasks.

Database guardrails give a new approach to database reliability. We don’t need to fix issues manually. Database guardrails can identify issues much earlier, detect anomalies, and fix problems automatically. This way, DBAs can shine and focus on the business, and developers feel responsible and accountable for their work.