The DBA’s Role in a World That Thinks It Doesn’t Need DBAs

In a world of automation, AI and "self-managing" databases, the role of the DBA has become misunderstood, Craig Mullins writes

For decades, the database administrator (DBA) has been a central figure in IT. Every organization depends on data, and organizations relied on DBAs to design, manage, tune and protect the systems that stored that data. Sadly, at many sites, that role is often viewed as optional these days.

Modern data platforms promise “self-managing” databases. Cloud providers advertise automated scaling, built-in high availability and AI-driven tuning. Development teams spin up databases with a few clicks. Data engineers build pipelines without ever speaking to a DBA. And this has changed the way some organizations staff database administration.

At some, the DBA team has been shrunk due to attrition and layoffs. At other, the role has been reduced, reassigned or eliminated entirely. And yet, the need for database expertise has not gone away. In many cases, it has increased.

The problem is not that DBAs are no longer needed. The problem is that their role is being misunderstood.

From Custodian to Consultant

Historically, DBAs were seen as custodians of the database, responsible for installing and configuring database systems, managing storage and backups, controlling access and tuning performance.

These responsibilities still exist, but they are now partially automated or are claimed to be abstracted away by modern data platforms. As a result, organizations assume the role itself can be abstracted away as well. But that assumption is flawed.

What has changed is not the need for expertise, but the point at which it must be applied.

Today’s DBA must operate less as a gatekeeper and more as a consultant. DBAs need to be the data professional who guides decisions rather than enforces them. The focus shifts from “owning the database” to influencing how data is designed, accessed and managed across a distributed environment. When the DBA acts as a consultant:

• Instead of approving every database change manually, the DBA would define patterns, standards and guardrails that teams can use independently.
• Instead of physically managing every schema update, the DBA would advise teams on data modeling choices, naming conventions and how to keep definitions consistent across systems.
• Instead of serving as the sole access controller, the DBA would help design role-based access policies and data classification rules that can be applied at scale.
• Instead of owning backups and recovery in isolation, the DBA would help establish resilience strategies for distributed systems, including replication, retention and restore testing.
• Instead of reacting to issues after they happen, the DBA would participate earlier in planning, helping teams make choices that avoid unnecessary complexity, duplication or cost.
• Instead of acting as a bottleneck for every decision, the DBA would become a trusted advisor who helps product, engineering and analytics teams use data responsibly and efficiently.

In practice, this means the DBA spends less time saying “yes” or “no” and more time shaping the rules, architecture and practices that let others move safely and effectively.

The Rise of Invisible Complexity

Modern data architectures are often described as simpler because infrastructure is easier to provision. However, beneath that simplicity lies a different kind of complexity that is easier to create but harder to control.

Consider what happens in a typical cloud-native environment:

• Multiple teams create databases independently.
• Data is replicated across systems for different use cases.
• Pipelines transform and move data continuously.
• Workloads span transactional, analytical and streaming systems.

No single person “owns” the data environment. And that is precisely where problems begin. Without a unifying perspective, performance issues become harder to diagnose, data definitions diverge across systems, costs grow without clear accountability, redundancy becomes the default and governance shifts from intentional to reactive.

This is not a failure of technology; it is a failure of coordination. And coordination is exactly where experienced DBAs add value.

Performance Is Still a Design Problem

One of the more persistent myths in modern data platforms is that performance tuning is no longer necessary. Instead of tuning the workload, the system gets scaled up. A general ideology that the cloud will absorb the load and the platform essentially optimizes itself prevails. But scaling hides problems, until it doesn’t.

Performance issues today are rarely caused by a single slow query. They emerge from multiple issues including inefficient data models, poorly understood access patterns, excessive data movement and competing workloads. These are not problems that automation can fully solve because they are rooted in design decisions.

DBAs have always understood that performance is not something you “add later.” It is something you design for from the beginning.

That insight remains just as relevant today. Actually, it is probably more relevant as there are more data sources, data pipelines and data platforms in use than ever before. Not to mention the key role data plays in creating AI models.

Cost Is the New Performance Metric

In traditional environments, performance was often the primary concern. Hardware was fixed, and the goal was to make the most efficient use of it. In cloud environments, inefficiency shows up differently. It shows up as cost.

Poorly designed queries, redundant pipelines, and excessive data duplication may still “work,” but they do so at a price. And that price is often hidden until it becomes significant.

This is where the DBA’s mindset becomes critical.

DBAs are trained to think in terms of efficiency:

• Minimizing unnecessary I/O
• Reducing redundancy
• Aligning structures with access patterns
• Understanding workload behavior

These same principles can be applied directly to cost management. In other words, the DBA is no longer just a performance expert. The DBA is a cost control expert.

Governance Without Friction

Governance is another area where the absence of DBAs is increasingly felt. In loosely governed environments, data proliferates. This exhibits itself in various ways including the creation of multiple versions of the same data set, inconsistent definitions complicating data usage, unclear or non-existent lineage making it impossible to track data accuracy, and varying levels of data quality causing users to distrust the data.

Attempts to impose governance after the fact often fail because they introduce friction, and teams resist centralized control when it slows down delivery. The DBA can play a different role here, not as an enforcer but as an architect of practical governance by defining standards that align with how teams actually work. When governance is embedded into pipelines and platforms, teams will more readily accept it. Likewise, promoting reuse instead of duplication and ensuring that critical data is clearly defined and consistently managed will help to bolster the acceptance of governance.

In the end, effective governance is not about control. It is about clarity.

The Risk of Losing Institutional Knowledge

One of the less obvious consequences of sidelining DBAs is the loss of institutional knowledge. Experienced DBAs understand not just database internals and procedures, but also the decisions made as enterprise databases and applications get built. They know how these systems evolved over time and why certain design decisions were made. Additionally, DBAs know where hidden dependencies exist, because they were there when those decisions were made. This knowledge of what worked and what failed (and why) is crucial to the ongoing operation of enterprise systems.

Without that perspective, organizations are more likely to repeat mistakes such as rebuilding systems that already exist, duplicating data, reintroducing known performance issues and underestimating the impact of change.

Indeed, technology may change rapidly, but lessons learned from managing data at scale remain highly relevant.

What About AI Replacing DBAs?

Artificial Intelligence is impacting most job roles these days, and it is fair to question how it will impact the DBA. Unfortunately, there are those who think AI can take over that role. AI can help, but it won’t replace DBAs.

Completely turning over the DBA role to an AI agent can introduce a range of technical, operational and organizational risks, especially in mission-critical environments. The biggest issues tend to surface where context, accountability and judgment matter more than optimization tweaks. Key issues that can arise include loss of business context, over-aggressive automation, trust gaps, workload regression, incident response limitation, security and privilege risk, skill atrophy and ambiguous accountability.

AI agents can be excellent DBA amplifiers, handling analysis, recommendations and repetitive tasks. This is a reasonable usage of AI for the DBA. But turning over full DBA authority to AI shifts risk faster than it removes effort. The safest model is to keep a human in the loop, where AI is aided by a human DBA. In this model, AI advises, simulates, and automates under guardrails, and humans retain final judgment and accountability.

The bottom line is that AI will not replace DBAs, but DBAs that use AI will replace DBAs that do not.

Redefining the Role

The challenge, then, is not to preserve the DBA role as it was, but to redefine it for the environment that exists today.

A modern DBA should be:

• A data architect, helping to shape how data is structured and shared
• A performance engineer, ensuring systems operate efficiently at scale
• A cost analyst, identifying and reducing unnecessary spend
• A governance advocate, promoting consistency without slowing innovation
• A systems thinker, understanding how components interact across the ecosystem

This role may not always carry the title “DBA.” It may be distributed across multiple positions. But the responsibilities do not disappear simply because the title does.

Conclusion: The Role Didn’t Go Away, It Went Unrecognized

The narrative that organizations no longer need DBAs can be appealing because it suggests simplicity. And that appeals to management. Fewer roles. Less overhead. More automation.

But data systems have not become simpler. They have become more distributed, more dynamic and more interconnected. And in that environment, the need for expertise does not diminish. It becomes more critical.

The real risk is not that DBAs are becoming obsolete. The real risk is that organizations stop recognizing the value DBAs provide and the critical role they play.

When the value of the DBA role is ignored, the consequences are not usually immediate, but they are almost always inevitable. And they are not good.

---