Itamar Syn-Hershko, Founder of NeverBlink AI and BigData Boutique, helps companies confidently operate and optimize data platforms at scale.
getty
Cloud operations agents are already being used to investigate incidents and, in some environments, take narrowly defined actions under policy controls. Teams running AWS and Kubernetes can use AI to restart pods, roll back deployments and perform other bounded remediation steps, provided the actions fall within predefined guardrails.
Databases are a different animal. A bad ALTER TABLE or a hallucinated migration doesn't self-heal the way a rescheduled pod does. Here is how database teams should actually adopt AI-driven operations, and where the line has to stay firm.
Imagine an AI SRE agent detects a failing deployment, correlates it with a fresh release and rolls it back before the on-call engineer finishes their coffee. Nobody panics, because a stateless pod is designed to be replaceable. Then the same AI SRE (or a general-purpose coding agent such as Claude Code or Codex) attempts to touch your database: tune your indexes, right-size your instances or even handle migrations.
The database behind those pods is not designed to be replaceable. A dropped column, a bad backfill or a lock-holding migration cannot be undone by rescheduling anything. The real question for leadership is not whether AI will replace the database administrator (DBA), but what AI should be allowed to decide unsupervised, and what must never be automatic.
That distinction raises a more fundamental question: What can these AI systems do today, and where are their limits?
What Is Already Real, And What Is Not
The genuinely useful capabilities today are narrower than the marketing suggests. AI SRE tools and frontier models can assist with tasks such as query and execution-plan analysis, index recommendations, maintenance tuning, anomaly detection across slow-query logs and metrics, schema-drift detection and capacity planning.
But that doesn't mean they can safely perform a DBA's job unattended. Research on occupational AI exposure puts database administrators at roughly 48% exposure, placing the role closer to "augment" than "replace." As AI takes on more of the routine analysis, the DBA's role is likely to shift toward strategy, oversight and approval.
The broader industry is arriving at a similar conclusion. Even leading incident-response platforms distinguish between autonomous investigation and autonomous remediation, with consequential actions often still requiring human approval. Gartner has likewise warned that more than 40% of agentic AI projects could be scrapped by 2027.
If that level of caution applies to restarting pods, it should apply tenfold to your system of record.
Why The SRE Playbook Breaks At The Database
General-purpose models, whether a coding assistant or an AI SRE agent with broad infrastructure context, share an important limitation: their knowledge may be broad, but it is not necessarily deep enough for the specific database they are being asked to manage. They may not have a complete understanding of engine-specific behavior, in-flight locks, workload dependencies or the downstream systems that depend on a particular column. Ask a general-purpose model to reason through a complex PostgreSQL workload or an unfamiliar engine such as ClickHouse, and it can produce an answer that sounds authoritative while missing important operational details.
That creates a database-specific failure mode I call functional hallucination: a database operation that is syntactically valid but semantically destructive. The danger isn't that every database action is irreversible. It's that many changes have durable, delayed or externally visible consequences that a rollback cannot fully unwind.
Wiring a generic LLM, however capable, directly into production data operations without an expert watching is a bet no board should knowingly take.
An Autonomy Ladder Databases Have To Earn
The answer is not zero AI. It is graduated, machine-enforced autonomy, with each level earned by demonstrating that the system can operate safely within defined boundaries.
Level 0: Observe
Read-only access to approved telemetry, execution plans and sanitized logs. The agent can correlate replication lag with write activity, identify plan regressions and surface anomalies, but it has no ability to modify the database or issue arbitrary SQL.
Level 1: Simulate And Recommend
The agent can perform hypothetical index analysis, replay workloads, estimate costs and generate proposed migrations with rollback and verification steps. This is the database equivalent of a shadow mode: the AI can reason about changes without being able to make them.
Level 2: Execute Bounded Actions
The agent can perform narrowly defined operations with machine-checkable preconditions, resource limits and abort criteria—for example, terminating a known runaway query, scaling an approved replica or applying a parameter change within a pre-approved range. Execution should flow through a deterministic control plane that enforces those boundaries rather than giving the model unrestricted authority to execute its own SQL.
Level 3: Human-Authorized Change
Higher-consequence operations, including schema changes, backfills, failovers and access or retention changes, require explicit human approval. The person approves the exact proposed change, along with its expected impact and rollback plan, rather than simply telling the agent to “fix the database.”
Level 4: Prohibited
Some actions should remain outside the agent's authority entirely: deleting backups, dropping production databases, weakening audit controls or modifying its own permissions and guardrails. These aren't merely actions that require approval; the agent should not have the credentials to perform them in the first place.
Conclusion
Three moves can help prepare you now:
1. Turn tribal runbooks into structured, machine-checkable policy.
2. Require every migration to carry machine-readable provenance and a rollback plan.
3. Write automation boundaries as enforced configuration, not as a policy document nobody reads.
And don't be tempted to connect a general-purpose coding assistant like Claude Code or a generic AI SRE agent to a production database and simply tell it to “fix it” without tested and guard-railed database expertise.
A credible "AI DBA" should be a specialized, multi-agent system with a policy gate in front of every consequential action, tailored to the specific engines you run. Until that exists and has been tested against your workloads, the human expert stays in the loop. The people who understand your database deeply are exactly the ones who must define these tiers, because you cannot write guardrails for actions you don't understand.
The goal is not less autonomy. It is earned autonomy.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?