Agentic AI Meets Database Development: What Changes When AI Can Actually Execute Queries

For the past few years, AI-assisted database development has followed a fairly comfortable model. A developer describes a requirement. The AI generates SQL. The developer reads it, changes what looks wrong, and decides whether to run it.

That workflow has kept one important boundary intact: AI can suggest an action, but a human still decides whether it reaches the database.

However, that boundary is beginning to disappear with agentic AI. Today, AI systems can inspect schemas, run queries, interpret the results, and decide what action to take next. According to a recent survey, 62% of organizations are already experimenting with AI agents, while 23% reported scaling an agentic system somewhere in the enterprise.

Database teams therefore have a fairly immediate architectural question to answer. Not whether AI can execute SQL. It can. The real question is what changes when an assistant stops suggesting code and starts acting on the database, and how tightly that autonomy should be controlled.

From Suggestions to Actions

One simple indexing decision shows why that shift matters.

An agent sees a slow query, looks up the schema, figures out an index might help, creates it, reruns the workload, and checks the result.

It might execute something as ordinary as:

CREATE INDEX IX_Orders_CustomerId  ON Orders(CustomerId);

There is nothing unusual about that statement. An AI assistant could have suggested the exact same thing. The difference is who makes the final call.

With an assistant, the developer reviews the recommendation, tests it, and decides whether to run it. The AI advises, but the human acts. With an agent that has execution rights, the system can make that decision itself and move on without waiting for approval.

If that decision is right, the workflow gets faster. But agents do not always have the full picture. They may miss application dependencies, business rules, workload patterns, maintenance windows, or other context that is obvious to the people running the system.

So an agent can make a technically reasonable looking decision and still be wrong for the environment it is acting in, given its specific constraints and requirements.

The danger increases as the actions begin to chain together. A bad SELECT may just run slow. A bad UPDATE can lock a whole big table or affect way more rows than intended. An index used for one query might be unnecessary but adds overhead to other queries. A schema change can break something the agent didn’t know depended on it because the agent may lack the full operational context and cannot test every possible use case.

So the issue is not that agents cannot make good database decisions. They often can. The issue is that once they are allowed to act on those decisions, teams need to be much clearer about how far that authority goes, what context the agent can see, and where a human still needs to step in, and who remains accountable for the outcome.

Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, partly because of inadequate risk controls. For database teams, the lesson is fairly simple: execution rights should come after the controls, not before them.

What Can Be Safely Delegated?

Some database tasks are much safer to hand over than others.

Query analysis is a good example. An agent can inspect query statistics, pull execution plans, check indexes and table structures, and suggest likely fixes without changing production data.

It might spot a query like this repeatedly scanning a large Orders table:

SELECT OrderId, OrderDate, Total  FROM Orders  WHERE CustomerId = @CustomerId  ORDER BY OrderDate DESC;

From there, it can explain the scan, suggest an index, and generate the DDL. It does not need permission to run CREATE INDEX to be useful.

The same applies to tasks such as:

• Describing execution plans;
• Identifying missing or unnecessary indexes;
• Flagging SELECT * queries or non-sargable predicates;
• Reviewing join and filter pushdown;
• Reviewing dependencies and schemas;
• Troubleshooting SQL errors;
• Optimizing SQL scripts.

The practical split is simple: give the agent enough access to understand the problem, but not automatically enough access to change the database. Broad visibility can be useful, but broad execution rights are a different decision.

Where Human Control Still Matters

Some database decisions still need a human in the loop. Say an agent finds an AuditLog table with hundreds of millions of rows and decides old records should be deleted:

DELETE FROM AuditLog  WHERE CreatedAt < DATEADD(year, -2, GETDATE());

The SQL can be perfectly valid and still be a terrible decision.

Perhaps regulatory policy requires seven years of retention. Maybe an application depends on those records. Perhaps the deletion should happen in batches to avoid transaction-log growth. Maybe records must be archived before removal.

None of those requirements necessarily exist in the schema.

This is one of the limits of treating database work as a code-generation problem. Databases contain technical structures, but the decisions around them are often business decisions expressed through technical operations. The same caution should apply to operations such as:

• DROP and destructive ALTER statements;
• production UPDATE and DELETE operations;
• large data migrations;
• role and permission changes;
• constraint modifications;
• changes affecting replication or availability;
• deployment of stored procedures containing business logic.

A technically correct action is not necessarily an appropriate action. Human approval therefore should not be viewed as an inconvenient limitation on agentic AI. For high-impact database operations, it is part of the architecture.

AI Agents Need Least Privilege Too

One shortcut database teams should avoid is letting an agent use a developer’s existing credentials. It is easy, but it gives the agent whatever access that developer already has.

The safer approach is the same one used for users and services: least privilege. Microsoft recommends granting only the permissions required for the task and monitoring privileged activity.

A performance-analysis agent, for example, might need:

CONNECT  SELECT  VIEW DATABASE STATE  VIEW DEFINITION

It probably does not need:

ALTER ANY TABLE  CONTROL DATABASE  db_owner  sysadmin

Different agents can also have different identities. A reporting agent might get SELECT access to a few schemas. A migration agent might work only in development or staging. A production agent might get tightly scoped permissions and still require approval before it can execute.

OWASP recommends the same basic pattern for AI agents: separate read and write access, limit tools and resources, and require explicit authorization for sensitive actions.

The rule is simple: give the agent the permissions its job needs, not the permissions of the person who launched it.

Build the Human Into the Workflow

A better model for agentic database work is a controlled workflow:

Observe → Analyze → Propose → Review → Execute → Validate → Record

Say an agent is investigating a slow API endpoint. It finds the SQL behind it, checks the execution plan and table statistics, spots a likely missing index, and prepares a migration script.

That script can run in staging first. The agent reruns the workload, checks the result, and prepares the production change.

Then it stops.

A developer or DBA reviews the migration, checks dependencies and business impact, and approves it before anything reaches production.

The agent can still handle a lot of the repetitive work. What stays with the human is the final responsibility for a high-impact change.

Transaction controls can add another layer of safety. PostgreSQL savepoints, for example, allow part of a transaction to be rolled back without discarding everything that came before it. That can help with tightly bound automated changes, although rollback is not a substitute for proper permissions and approval.

This is also where tools like dbForge AI Assistant fit naturally. It can use schema context to generate and explain SQL, troubleshoot errors, compare DDL, spot inefficient indexes, and prepare optimization scripts while keeping the resulting SQL visible for developer review.

The goal is to automate the routine work while keeping important decisions human.

The Real Goal Is Controlled Autonomy

Agentic AI does not have to mean choosing between “AI only suggests” and “AI runs the database.” There is a lot of room in between.

Teams can begin with lower risk tasks such as explaining SQL, reviewing schemas and performing read-only checks. From there, agents can take on more work in dev and staging gradually.

Write access should be much later, and with clear limits around affected rows, transactions, rollback, monitoring, and approvals. Fully autonomous changes in production should be rare.

That’s also similar to Deloitte’s guidance: start with lower-risk workflows and noncritical data, keep folks in the loop and bolster governance as agents get more.

The aim is not absolute autonomy. It’s giving the agent enough freedom to help, but not more access than it needs.

Takeaway: Database Development Still Needs Judgment

AI agents can take a lot of repetitive work out of database engineering. They can see workloads, examine queries, correlate schemas, plans, errors and performance data and act on what they see.

But once an AI system can modify the state of the database, the problem changes. Teams need clear rules for identity, permissions, transaction boundaries, approvals, observability, rollback, and audit trails.

That’s why of 88% of organizations using AI in 2025, only 7% said it had been fully scaled across the organization. The harder problem is making AI dependable enough to operate at scale.

Database development is heading in the same direction. The most useful agent will not be the one allowed to do the most, but the one whose authority is clearly understood and controlled.

The question is no longer whether AI can execute database tasks, but which tasks we should trust it to execute, and under what constraints.