Should you let AI write and merge your database migrations?

Yes — if a check reads the schema diff before it merges. The danger with an AI-generated migration is not that it fails loudly; it is that it succeeds quietly. An agent asked to “rename the column” or “tidy up the users table” will produce something that applies cleanly, passes your unit tests, and reads well in review — while dropping a column three other services still select.

Why AI migrations are a distinct risk

A human writing a migration carries context: they remember that login_count feeds a dashboard, or that an external consumer reads users.email at its old width. An agent working from the diff in front of it usually does not. It optimizes for a change that looks correct and applies without error — and “applies without error” is precisely the property a breaking change has. Dropping a column, narrowing a type, or removing an enum variant are all perfectly valid SQL.

It also happens faster and more often. The volume of migrations rises, review attention per migration falls, and the reviewer is frequently reading generated SQL they did not write. That is a good moment to have a machine check the one thing a machine is reliably good at: comparing two schemas.

The fix is a diff, not distrust

You do not need to ban AI from touching the database. You need the same thing you would want from a careless human: a check that reads the schema the change would produce and refuses the merge if it breaks a reader. Concretely, in CI on every pull request:

1. Build a throwaway database and apply the pull request’s migrations.
2. Introspect the resulting schema.
3. Diff it against the baseline from your default branch.
4. Fail the build on a breaking change — a dropped column, a narrowed type, a removed enum variant, a new NOT NULL — with a comment naming each one.

This is author-agnostic on purpose. The gate does not care whether a person or an agent wrote the migration; it reads the diff either way. And because the verdict posts as a Check Run and a pull request comment, an AI agent that opened the PR can read the failure through the GitHub API and fix its own migration — the same signal a human gets.

Where this stops

A schema diff catches structural breakage, not semantics: it will not tell you the agent renamed a column to something misleading, or that a backfill is wrong. It also reports that the schema broke, not which downstream dashboards depend on it — that tracing is not built yet. Treat it as the fast, mechanical layer under human review, not a replacement for it.

SchemaDrift Guardian is exactly this check. The quickstart sets it up in about ten minutes, and the database-safety-in-CI page covers the rollout. It is free while in early access.