ecc-database-migrations

Add the column as nullable or with a default value, which PostgreSQL 11+ applies instantly without rewriting the table. Never add a NOT NULL column without a default on an existing table, since that forces a full table rewrite and lock.

Use the expand-contract pattern instead of a direct rename. Add the new column, backfill existing rows, deploy code that writes to both columns, switch reads to the new column, then drop the old column in a later migration.

A plain CREATE INDEX blocks writes while the index builds on large tables. Use CREATE INDEX CONCURRENTLY instead, which allows concurrent writes, though it cannot run inside a transaction block and may need special handling in migration tools.

Prisma cannot generate CREATE INDEX CONCURRENTLY automatically. Create an empty migration with prisma migrate dev --create-only, then write the concurrent index SQL manually in the generated migration file.

No, schema and data migrations should be separate. Mixing DDL and DML in one migration creates long transactions that are hard to roll back. Apply the schema change first, then run a batched backfill as its own migration.

Never edit a migration that has already run in production, because it causes schema drift between environments. Migrations are immutable once deployed; create a new forward migration to correct or extend the change instead.