database-migrations

Zero-downtime database migrations use the expand-contract pattern to separate schema changes from data backfills. This approach safely adds new columns, performs controlled updates, and contracts old schema across PostgreSQL and MySQL without locking tables.

Common database migration anti-patterns include executing manual SQL in production, dropping columns prematurely before application updates, and leaving migrations untracked. These practices cause data inconsistency and unexpected downtime during schema deployments.

Yes, this database migration guidance covers tool-specific workflows for Prisma, Drizzle, Kysely, Django, TypeORM, and golang-migrate. It provides concrete examples for planning and implementing safe schema changes within these ORM environments.

Forward-only migrations handle rollbacks by applying a new compensating migration rather than reverting the database state. This ensures data integrity by moving the schema forward while safely undoing the effects of the previous deployment.

You should separate schema changes from data migrations to maintain zero-downtime during deployment. This separation allows the database to accept new structures first, followed by controlled data backfills without locking tables or blocking application traffic.

Validating data integrity after a database migration involves testing the deployment in staging and running post-migration checks. This operational readiness step verifies that UP and DOWN migrations, default values, and concurrent indexes function correctly before production release.