Database migration best practices for schema changes, data migrations, rollbacks, and zero-downtime deployments across PostgreSQL, MySQL, and common ORMs (Prisma, Drizzle, Kysely, Django, TypeORM, golang-migrate).
SkillScore100Maintained
Automatic
◆Data Engineer pack
Last verified 8/22/2026
What it changes
Passed 23 of 23 test cases with the skill, and 22 of 23 without it.
Without skill96%
With skill100%
Checks it passed that the model alone missed
recommends separating the DDL schema creation and DML data insertion into distinct migration files
1 fixed22 passed either way0 still failing0 broke
Pass-rate lift
+4 pp
Tokens
+135%
Agent turns
0%
Response time
-27%
Model gemini-3.6-flashMeasured 8/22/2026v623 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
A test case the skill fixed. Same model, same prompt, with and without the skill.
Prompt
A developer submitted a PR containing a single migration file that executes `CREATE TABLE products (...)` and inserts 50,000 seed rows via `INSERT INTO products ...`. How should this migration be structured for production safety?
What was checked, without and with the skill
Checked
Without skill
With skill
recommends separating the DDL schema creation and DML data insertion into distinct migration files
Missed
Passed
case-05 · gemini-3.6-flash · 8/22/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md430 linessingle file
Database Migration Patterns
Safe, reversible database schema changes for production systems.
When to Activate
Creating or altering database tables
Adding/removing columns or indexes
Running data migrations (backfill, transform)
Planning zero-downtime schema changes
Setting up migration tooling for a new project
Core Principles
Every change is a migration — never alter production databases manually
Migrations are forward-only in production — rollbacks use new forward migrations
Schema and data migrations are separate — never mix DDL and DML in one migration
Test migrations against production-sized data — a migration that works on 100 rows may lock on 10M
Migrations are immutable once deployed — never edit a migration that has run in production
Migration Safety Checklist
Before applying any migration:
Migration has both UP and DOWN (or is explicitly marked irreversible)
No full table locks on large tables (use concurrent operations)
New columns have defaults or are nullable (never add NOT NULL without default)
Indexes created concurrently (not inline with CREATE TABLE for existing tables)
Data backfill is a separate migration from schema change
Tested against a copy of production data
Rollback plan documented
PostgreSQL Patterns
Adding a Column Safely
-- GOOD: Nullable column, no lock
ALTER TABLE users ADD COLUMN avatar_url TEXT;