Ask a DBA what their week looks like and you’ll hear a familiar list: provisioning requests, capacity planning, failover runbooks, and firefighting. That operating model worked when a DBA managed 10 or 15 databases. It doesn’t work when the estate grows to 150.
The DBA role isn’t disappearing. It’s evolving from operating individual clusters to designing how the entire database estate runs.
Why is the traditional operating model breaking?
Three forces are accelerating database growth.
AI workloads have disrupted conventional capacity planning. Instead of following predictable growth patterns, GenAI inference and retrieval-augmented generation workloads are bursty and difficult to forecast. They also introduce new infrastructure, including vector stores, feature stores, and caching layers.
Multi-tenant SaaS architectures create another form of sprawl. Application teams need isolated environments, resource guarantees, performance SLAs, and protection from noisy neighbors. Assigning each team its own cluster may work for five teams; at 50, it becomes difficult to operate.
FinOps adds pressure from the other direction. Finance teams can now see database spending and utilization by team, turning questions such as “Why is this cluster running at 12% utilization?” into operational priorities.
The result is an estate that grows faster than the team responsible for managing it. In a December 2025 Wakefield Research survey across 11 markets, 83% of infrastructure teams said they expected their current infrastructure to hit its limit.
Why is DBA judgment difficult to automate?
Automating a provisioning workflow is relatively straightforward. Encoding the judgment behind it is harder.
DBAs routinely make decisions that depend on context:
What is the cost ceiling for this workload?
Which databases can scale automatically?
Which changes require human approval?
How much load can a cluster tolerate given the other workloads running on it?
These decisions reflect experience accumulated over years. A scalable platform must give DBAs a way to express that knowledge through policies, not attempt to replace it.
Retention rules, compliance boundaries, cost thresholds, resource limits, and performance SLAs can all be defined once and enforced consistently. Instead of reviewing the same routine request repeatedly, the DBA establishes the conditions under which the platform can act.
What happens when policy cannot anticipate a failure?
Policy governance has limits. Production incidents do not always fit established rules, and excessive abstraction can separate operators from the systems they need to understand.
A policy layer cannot anticipate every unusual failure or reproduce an experienced DBA’s intuition, and it shouldn’t try. Its purpose is to handle predictable decisions so DBAs can focus on incidents that genuinely require human judgment.
Its purpose is to handle predictable decisions so experts can focus on the exceptions. If routine provisioning, capacity checks, and resource controls are automated, the DBA is better prepared for the production incident that genuinely requires human judgment.
How does cluster virtualization change the DBA’s role?
Cluster virtualization makes this governance model practical.
An operator creates a host cluster and defines workspaces with policies governing resources, regions, and operational boundaries. Development teams then create virtual clusters that inherit those policies automatically:
The host cluster provides the governance boundary.
Workspaces define and apply policy.
Virtual clusters provide isolated environments for workloads.
Development teams can provision the database resources they need without opening a ticket for every request. DBAs retain control over the cost, compliance, reliability, and performance requirements that matter across the estate.
That is the estate architect role: designing the policy structure within which teams and workloads can operate safely.
By 2028, the most valuable DBAs will be those who can translate technical expertise and business requirements into policies that govern the entire estate.
The database estate is already changing. The operating model now has to catch up.
Cockroach Continuum’s Cluster Virtualization is available in public preview: Try it
