Database migration prompts should describe how old and new application versions coexist, not just the final schema. A renamed field can be valid in a fresh database and still break a running service during deployment. A backfill may finish on a development table but contend with real traffic. This collection helps plan staged changes, review generated operations and verify partially completed work without assuming every change is reversible.
Provide the workload as well as the schema
Include the database engine and version, schema, approximate row counts, write rate and deployment sequence. Explain the largest acceptable interruption and any constraints on backups or replicas. Use representative shapes instead of exporting production records into a prompt. State whether the task is planning, SQL review or an authorized execution in a specific environment.
For PostgreSQL, the ALTER TABLE reference documents operation-specific behavior and locking. Other engines differ. Ask the agent to verify each proposed operation against the actual engine rather than applying one database's rules everywhere.
Plan a compatibility window
A staged plan should identify which application versions can read and write each schema state. Adding a replacement field is only the beginning: the team also needs a rule for populating it and deciding when old readers can disappear. Ask for completion criteria for every phase so cleanup does not depend on an assumed deployment date.
Plan the migration from {{current_schema}} to {{desired_behavior}}.
Database and version: {{database_version}}. Workload: {{workload}}.
Deployment constraints: {{deployment_constraints}}.
Show schema states, compatible app versions, read/write behavior and exit
criteria for each phase. Review lock and data-loss risks per operation.
Separate preparation, backfill, cutover and cleanup. Do not execute SQL.
Design a resumable backfill
The key question is what happens after a worker stops halfway through. A useful backfill has a clear checkpoint, bounded batches and a rule for concurrent updates. Ask how repeated processing affects the same row. If the transformation is lossy, preserve the evidence needed to investigate a wrong result before removing the original data.
Design a backfill for {{transformation}} on {{table_details}}.
Specify batch selection, ordering, checkpointing, retry behavior and
handling of rows modified during the run. Define progress and error
metrics, a stop condition and a small rehearsal dataset.
Explain how to resume after partial completion without duplicating or
silently overwriting newer data. Return a plan before implementation.
Review operations and recovery together
Do not accept a rollback section that only says to run the down migration. Ask which data remains available after each operation. Recovery may mean restoring a backup, replaying an event or deploying a compatible forward fix. The right choice depends on the actual failure and the time the service can tolerate.
Review {{migration_sql}} against {{database_version}} and {{traffic}}.
For each operation, identify prerequisites, expected locks, rewrite or
validation work and compatibility with the previous app version.
Give preflight checks, postflight queries and a recovery option for
failure before, during and after cutover. Mark unknowns requiring a
rehearsal; do not label the migration zero-downtime without evidence.
Define success with checks the team can run
Confirm more than the existence of a new column. Compare record counts, transformed values, invalid rows and application reads. Keep checks bounded enough to run safely on the target environment. Record the migration identifier, rehearsal conditions and measured results so later reviewers understand what was actually established.
Store the approved planning prompt in Kipt, keeping environment credentials outside it. For ORM-generated changes, continue with the Prisma prompts; for query plans and index tradeoffs, use the PostgreSQL prompts.