Write a migration to {{describe what — add column, rename, split table, change type, etc.}}.
Database: {{Postgres / MySQL / etc.}}
Migration tool: {{Alembic / Flyway / Knex / Prisma / raw SQL / etc.}}
Current state:
{{paste current schema for affected tables}}
Target state:
{{paste target schema}}
Output:
1. **The "up" migration** — DDL + any data backfill needed
2. **The "down" migration** — actually reverses, not just "// can't roll back"
3. **Locking concerns** — what'll lock the table, for how long, on a 50M-row table
4. **Order of operations if running on a live DB** — what to do before, during, after deploy
5. **What could go wrong** — concrete failure modes I should be ready for
If the change isn't safe to do in one step (e.g., NOT NULL + default on huge table), tell me to split it into multiple migrations and explain the sequence.Tip: Always test on a staging DB with realistic data volume before running in production.
databasemigrationsschema