DevOps for databases has no shortage of technical challenges, but the hardest problem to solve is cultural. Developers push for speed and flexibility; database administrators (DBAs) push back to protect data integrity, established processes, and—sometimes—their own job security. When the two sides cannot find common ground, IT automation stalls entirely.
“We have such a bad relationship with our DBAs on the operations side that we only talk to them for production changes.”
— Daniel MacDonald, architect and principal technical lead, New York public utility agency
MacDonald’s situation is not unusual. In many enterprises, production databases are locked down so tightly that developers cannot debug or tune application performance in that environment. That arrangement is incompatible with DevOps, where cross-functional ownership is the norm.
“DBAs have to either start learning new things or be left out in the cold,” MacDonald said. He also argued that DBAs should be more open to how modern application architectures—such as containers—can actually improve database operations rather than threaten them.
DBAs Hold Their Own Despite DevOps Momentum
Some DevOps advocates envision cloud-managed database services eventually replacing the need for dedicated DBAs. In reality, many enterprises depend on DBAs who carry irreplaceable institutional knowledge about data structures, stored procedures, and legacy integrations that exist nowhere else in the organization.
Consider the case of a DBA at LogistiCare Solutions, a nonemergency medical transportation company headquartered in Atlanta. This individual has been with the company since its application ran on Btrieve, a data management engine from the 1980s, and personally oversaw the migration to IBM DB2.
“The only guy that knows the stored procedures is Andy. Our relationships are managed in stored procedures, and they’re not well-documented.”
— Michael Quintero, enterprise solutions architect, LogistiCare Solutions
Quintero acknowledged the DBA’s limits as well: deep familiarity with the existing system did not automatically translate to expertise in new capabilities. When LogistiCare added IBM HADR (High Availability Disaster Recovery) to DB2, the company brought in an outside specialist to oversee the implementation and later outsourced day-to-day database management to a third party.
Outsourcing introduced its own cultural friction. Communication moved through a ticketing system, eliminating the informal, rapid-response conversations that happen naturally when a DBA sits in the same building as the development team. Availability and responsiveness became subject to a service contract rather than organizational priorities.
The DBA in this story did adapt: he eventually transitioned into managing an IBM Netezza data lake used for reporting and analytics. Not every database professional navigates that kind of transition successfully, however.
IT Roles Must Evolve for DevOps and Databases to Coexist
Resolving the cultural standoff between developers and DBAs requires both sides to change. The risk of keeping them completely siloed is well-documented. The risk of moving too fast in the opposite direction is equally real: GitLab’s 2017 data-loss incident, in which a new team member with insufficient guardrails accidentally deleted a production database directory, is a widely-cited example of what happens when access control and process discipline are not part of the DevOps conversation.
Some organizations have found a workable balance by rethinking job boundaries rather than eliminating roles.
A Real-World Example: Jamf
At Jamf, a mobile device management software company based in Minneapolis, the lone DBA on staff operates as a true cross-functional contributor, according to Michael Kren, Manager of DevOps at the company. That DBA’s responsibilities include:
- Writing automation scripts around Amazon Relational Database Service (RDS)
- Troubleshooting MySQL and PostgreSQL installations
- Consulting with engineers who have database questions
- Systems administration work using Ansible playbooks and AWS CloudFormation templates
At the same time, Jamf’s DevOps engineers have expanded their own database competency. The team has taken on database containerization work and is actively running PostgreSQL inside Kubernetes clusters—a task that would traditionally have been the DBA’s domain.
Key Takeaways for Teams Navigating This Tension
- Tribal knowledge is a real risk: When critical database logic exists only in one person’s head, the organization is exposed regardless of which side of the DevOps debate that person sits on. Documentation and knowledge transfer are non-negotiable.
- Access without guardrails is dangerous: Giving developers more database access must be paired with clear policies, testing environments, and audit trails. The GitLab incident is a useful case study in what goes wrong when this is skipped.
- Outsourcing removes human bandwidth but adds process overhead: Managed database services can reduce operational burden, but they change the communication model in ways that can slow incident response and reduce organizational learning.
- Role evolution, not role elimination, is the pragmatic path: Organizations that have made progress tend to expand what DBAs do—into automation, cloud services, and DevOps tooling—rather than simply replacing them with self-service tools.
- Trust is bidirectional: Developers need to earn the right to touch production databases through demonstrated discipline. DBAs need to demonstrate value beyond gatekeeping by contributing to speed and reliability goals.
The cultural gap between development and database operations is narrowing at organizations that treat it as a structural problem rather than a personality problem. Changing job descriptions, investing in cross-training, and establishing shared ownership of database reliability are more durable solutions than waiting for one side to capitulate to the other.
This article is based on reporting originally published by TechTarget’s SearchITOperations in 2017. The specific company details and quotes have been preserved from the original sourced content.