# Database Migration Change Planner

Plan a schema or data change for an AI-built app with compatibility, backfill, validation, rollback, and deployment sequencing.

## Prompt

You are a database change engineer who specializes in safe schema evolution for small production applications.

Inputs:
1. Current schema, data volume, and database engine: {{current_database}}
2. Requested product change and target schema: {{requested_change}}
3. Application reads, writes, queries, and generated types: {{application_usage}}
4. Deployment model, traffic, and migration tools: {{delivery_context}}
5. Downtime, privacy, backup, and rollback constraints: {{constraints}}

Do the following:
1. Explain why the change is needed and map every affected table, constraint, index, query, API, type, seed, policy, and user-visible behavior.
2. Classify the migration as additive, destructive, data-transforming, or constraint-tightening, and identify compatibility risks between old and new application versions.
3. Design an expand-migrate-contract sequence where appropriate, including nullable transitions, dual read or write behavior, backfill batching, validation, and cleanup.
4. Define backup, lock, timeout, transaction, row-level security, data-retention, failure-recovery, and rollback considerations without assuming every migration is safely reversible.
5. Produce migration steps, SQL or pseudocode outline, application-change sequence, validation queries, rehearsal plan, monitoring, stop conditions, and post-migration cleanup. Clearly label engine-specific details that require verification.

## Best for

Vibe coders changing a live database who need more than an autogenerated migration file and a hopeful deploy.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Include the current schema and representative queries.
- State data volume and deployment behavior.
- List generated types, policies, and imports affected.
- Rehearse the migration against a production-like copy.

## Customization tips

- Prefer additive transitions for rolling deployments.
- Define validation queries before running the backfill.
- Protect tenant isolation during every phase.
- Separate rollback from irreversible cleanup.

## Example input

Database: Supabase PostgreSQL with 180,000 task rows. Change: replace free-text project_status with a normalized statuses table while preserving custom labels per workspace. Usage: dashboard filters and reports read the text value; imports write it directly; generated TypeScript types are committed. Delivery: Vercel app with rolling deployments. Constraints: no downtime, existing reports must remain accurate, RLS must continue isolating workspaces, and rollback cannot lose newly entered labels.

## Example output

The plan uses an additive statuses table and nullable status_id, seeds distinct labels per workspace, backfills in batches, and updates RLS before application reads switch. During transition, imports resolve or create status records while retaining the legacy text field for compatibility. Validation compares counts and labels by workspace. Cleanup occurs only after old versions stop writing and report parity is confirmed; rollback returns reads to the retained text field without discarding new status records.