Google's Database Agent Will Add the Index. Data Is the One Thing You Shouldn't Vibe.

On August 4, Google shipped two database agents and described one of them in a sentence worth reading twice: it "can execute validated actions with your approval."

The example Google gives is adding an index to a Cloud SQL instance. The agent spots lock contention — requests piling up behind each other waiting on the same rows — correlates telemetry across Database Insights, Cloud Monitoring, Cloud Logging and Cloud Trace, works out what's causing the slowdown, proposes the fix, and, once you click, applies it to a production database.

That's a real capability and the engineering behind it is good. What it asks of you is the interesting part. An approval gate only does work when the person standing at it could have authored the thing they're approving. Otherwise it's a signature.

What Google's database agents actually do

Two agents, split by lifecycle stage.

The Database Onboarding Agent handles Day 0. You describe a workload in plain language — throughput, scale, data shape, availability requirements — and it recommends a managed service, then generates the provisioning and configuration commands. Google's own example is reflecting the requirements back and recommending AlloyDB for a high-availability configuration. It covers AlloyDB, Bigtable, Cloud SQL, Firestore, Memorystore and Spanner, and it's generally available through Gemini Cloud Assist.

The Database Observability Agent handles Days 1 and 2. It correlates telemetry across four Google services, does root-cause analysis "in minutes," and answers fleet-level questions like which databases burned the most CPU in the last seven days. It runs in Cloud Assist chat, on the database console pages, in the CLI, and inside your IDE through MCP tools. The chat and fleet-query pieces are generally available. The two pieces that matter most — in-product investigations and validated remediations — are in preview with select customers.

Read past the launch framing and the scope here is operations — keeping a database healthy, fast, and correctly configured. Schema design stays with you. What the agents do is diagnose, recommend, tune, and, with a click, reach into a running database and change something. That boundary matters. Running a database and designing one fail in completely different ways, and the propose-then-approve pattern is heading for both.

Is an approval gate real database governance?

Approving something requires the ability to reject it for the right reason. That's the part the interface can't supply.

When the agent proposes an index to relieve contention on a busy table, a reviewer who knows data modeling works through a specific list. Whether the new index duplicates coverage an existing one already provides. What it costs on write speed for a table that takes constant inserts. Whether the contention is really a symptom of one table carrying two different things at once, in which case the index buys three months and buries the actual problem. Whether the slow query it's optimizing for is a permanent part of how the system works or an artifact of a report somebody runs at month-end.

A reviewer without that background works through a shorter list: does the explanation sound plausible, and has this system been right before? Both people click the same button. Only one of them reviewed anything.

This is the same accelerant that shows up when a language model writes the migration — each change locally correct, none of them evaluated against the data model as a whole. The agent has telemetry the ORM never had, which makes its recommendations better and the pattern more seductive. It still doesn't know that the table it's indexing is scheduled to be split apart next quarter, or that a second system reads from it through a view nobody documented.

Which makes the gate's value inversely proportional to the expertise of whoever's clicking it. That produces two pieces of advice, and they point in opposite directions.

If you're not a data expert, keep the gate

Most people who end up responsible for a production database didn't choose to be. Project managers who inherited an application when the original team rolled off. Front-end developers who own the whole stack because the company has four engineers. Backend generalists who are good at services and have never tuned a query plan in their lives.

For that group, this release is a straightforward upgrade. An agent that pulls together four monitoring sources and tells you your slowest requests are all queueing behind one table beats what you had, which was a dashboard nobody taught you to read and a Stack Overflow answer from 2019. Take the help.

Two rules if that's you. Keep the approval gate on, and never automate past it — the moment a remediation applies itself, you've handed the data layer to a system that optimizes for the symptom it was pointed at. And make the agent explain the change until you understand it, then write down what it told you. Every remediation you approve is a free lesson in why your database behaves the way it does, and the alternative is arriving at a rewrite in eighteen months with a production system nobody on the team can reason about.

The gate is a floor, and a floor is worth having.

Why data experts shouldn't vibe the schema

If you can model data, the gate is the wrong tool for you, because approving is a weaker act than authoring and it feels like the same job.

I've been on the wrong side of a milder version of this. I designed the entities myself — that part I've always held onto — but on more than one project I let Entity Framework influence the relationships and the index keys. EF's built-in conventions will infer a foreign key from a property name and put an index on it without being asked, and what came out of the first pass was reasonable and defensible, so I let it stick. In a few of those cases a deliberately denormalized shape would have fit the actual access patterns better than the normalized one EF steered me toward. I paid for it later, in index refactoring, on tables that were much bigger by then.

EF wasn't wrong. It was doing the only thing it could do, proposing the general-case shape, because it can't know the queries you'll actually be running in year two. The lesson landed somewhere else: a default is a suggestion that arrives looking like a decision. Accepting the general case is a choice, and the whole problem is that it never feels like one at the time.

That's why the data model is the artifact where I hold the pen. It's the only layer where mistakes compound silently instead of failing loudly. Application code that's wrong throws an exception. A schema that's wrong just gets more expensive, quietly, on a table that grows every day.

Same rule applies to the agent, only more so. Let it write the endpoint. Let it write the tests, the migration script, the Terraform. When it touches the shape of the data or the rules that protect it, you're authoring and it's assisting — reversed from everywhere else in the stack, and deliberately so.

The review that counts sits upstream of that button anyway. Somebody owns schema changes as a governed process, with a name attached and accountability for what all those changes add up to. If that name is "whoever was on call when Cloud Assist flagged it," you don't have a governance model. You have a queue.

The Day 0 decision no approval gate covers

Most of the coverage is about the agent that fixes things. The bigger exposure sits at the other end of the lifecycle.

The Onboarding Agent takes a plain-language workload description and recommends a managed database service. AlloyDB or Spanner or Firestore or Bigtable — that pick determines how your data stays consistent, what you can query and how fast, how the system grows, and what it will cost to move off later. It gets made on Day 0, by someone describing a workload they haven't built yet, from requirements that will be wrong in six months. No approval gate covers it, because choosing a platform doesn't look like changing anything. It's a recommendation made once that everything downstream then spends years living with.

That recommendation is probably better than what a team would have picked from a blog post and a pricing page, since it at least asks about throughput and availability. The discipline problem just moves up a level: profiling the workload honestly before matching it to a platform is the work, and a system that produces a confident answer from a two-paragraph description makes it very easy to skip.

The remediation feature is in preview with select customers. The onboarding agent is generally available right now.

Should I let an AI agent change my production database?

With an approval gate and a human who understands the change, yes — index and configuration tuning is a reasonable place to accept agent help. Never enable automatic execution on a production data store.

Do AI database agents design schemas?

Google's agents don't. They handle provisioning, diagnosis, and performance remediation. Schema design is still yours, and it's the layer where an agent's lack of whole-system context costs the most.

Who should own schema changes when an agent proposes them?

The same named person who owns them otherwise. An agent proposing a change doesn't transfer accountability for it, and "the tool recommended it" is not a review trail.

Google's approval button is the most honest thing in the release — an admission that this class of change still needs a person. Whether that admission means anything depends on which person is standing there. For the accidental database owner, the gate is the best feature shipped this month. For anyone who can actually model data, it's a chance to approve something you should have written.