AI Coding Agents
Platform Engineering
Safer database migrations with coding agents
September 24, 2026 - 2 minute read
Suppose an agent-generated database migration passes repository tests against a small fixture, but its backfill updates the entire production table in one transaction. The code can be correct while replication falls behind or locks delay application requests. Database migrations with coding agents need checks for both compatibility and the work imposed on the live database.
The established parallel-change pattern breaks an incompatible change into expand, migrate, and contract phases. Martin Fowler's description of parallel change emphasizes maintaining compatibility while callers move to the new interface. That sequence also gives a coding agent smaller tasks with clearer evidence.
Plan database migrations in phases
Start by writing the invariant that must remain true during deployment. For a column replacement, old and new application versions may need to read the same logical value. For a new constraint, existing rows must satisfy it before enforcement.
Ask the agent to produce separate changes for each phase:
- Expand. Add backward-compatible schema and code paths.
- Migrate. Backfill data in bounded batches and measure progress.
- Contract. Remove the old path only after every reader and writer has moved.
Bound the backfill by rows or a stable key range per transaction, and persist progress so an interrupted run can resume without repeating completed work. Select the batch size against an approved workload test. Rows remaining show progress, while lock waits and replication lag indicate whether the next batch should wait. A row count alone does not show that transformed values are correct.
Keep deployment and destructive operations outside the coding task unless they are explicitly authorized. The pull request should contain migration code, tests, operational notes, and rollback conditions. It should not run against a shared database merely because the agent can reach one.
Validate database migrations with coding agents
Run schema changes against an isolated database populated with representative data shapes. Include nulls, old enum values, duplicate keys, long rows, and partially migrated records where those states are possible. PostgreSQL's ALTER TABLE documentation shows that lock behavior and validation options vary by operation, so the review must consider the actual database and statement.
Check migration ordering and the rollback operations the framework actually supports. Run old and new application paths against the expanded schema to establish mixed-version compatibility. Then test the backfill's transaction bounds, restart behavior, and transformed values in the approved test environment. Measure lock duration and replication impact where the environment can represent them, and state what the test cannot predict about production load.
Factory's Missions can split a migration across planned milestones and validation checkpoints. The orchestrator can assign code, test, and review work separately while a human approves progress between phases. For pull requests, automated QA can scope test flows from the diff and preserve evidence.
Keep the production decision human
Database migrations need an owner, a maintenance or rollout plan, and a tested stop condition. Reviewers should know which statements acquire strong locks, whether the application tolerates mixed versions, and how long old data remains readable.
Use observability that reflects migration state rather than process completion. Track rows remaining, error rate, lock waits, replication lag, and application reads from the old path. A successful job exit does not prove that every record migrated correctly.
Coding agents are effective at the repeatable parts: locating callers, generating compatibility edits, writing fixtures, and running checks. Humans retain the production decision because workload timing, customer impact, and rollback tradeoffs depend on live conditions.
