Database migrations without downtime
summary
Claims that rollbacks are usually impossible for real systems and that safe migrations require multi-step, non‑destructive moves: add columns, dual writes (write old and new), backfill remaining rows, then switch reads and drop old fields. Recommends expand-contract for backward compatibility, use Flyway / doctrine / Liquibase for versioning, and for huge datasets use resumable background jobs, queues or CQRS to rebuild read stores instead of locking production with long ALTERs.
AI-written summary · about
chapters (29)
- 0:00Start
- 1:21ABOUT DATABASE MIGRATIONS
- 1:51ABOUT SCHEMA MIGRATIONS
- 5:03TRANSACTIONS?
- 5:20ROLLBACKS?
- 9:14DOWNTIME?
- 10:23NO MIGRATIONS!
- 11:11DATABASE STATE?
- 11:52OLD APP SHOULD WORK WITH NEW STATE
- 12:15DECOUPLE
- 12:31EXPAND - CONTRACT
- 12:52BACKWARDS COMPATIBILITY
- 13:33DEPRECATION
- 14:17NON-DESTRUCTIVE CHANGES
- 14:47ONE DIFF BACK
- 15:03EXAMPLE: RENAMING A COLUMN
- 16:25FEATURE TOGGLES
- 17:20NOSQL
- 17:46NO SCHEMA
- 18:10MIGRATE DURING READ
- 18:27BACKGROUND MIGRATION
- 18:37NO DOWNTIME
- 18:58LARGE DATASETS
- 21:05QUEUES
- 22:37COMMAND QUERY RESPONSIBILITY SEGREGATION
- 23:34SEPARATE READS FROM WRITES
- 25:11TOOLS
- 25:37RECAP
- 25:49NO BREAKING CHANGES
related talks
37mDatabase Schema Migrations with Zero Downtime
33mDatabase Schema Migrations with Zero Downtime
40mrails db:migrate:safely
34mZero Downtime Database Migrations and Deployments
47mMigrating to Microservice Databases
59mNavigating the Challenges of CI /CD for Relational Database Schema Changes
50mMigrating Your Most Critical Feature Without Regressions or Downtime
43mHow to avoid database migration hell