rails db:migrate:safely
summary
If a migration will touch tens of millions of rows this shows exactly what to do and what breaks: adding a column with a default triggers table locks, backfilling inside the implicit transaction blocks traffic for minutes, and a dropped/added index done wrong causes a 45‑minute outage. Concrete fixes include disable_ddl_transaction! and batched updates (example batch size 2000), using CREATE INDEX CONCURRENTLY on Postgres, testing with APM/Little’s Law in mind, and tooling like strong_migrations or zero_downtime_migrations.
AI-written summary · about
chapters (10)
- 0:00Start
- 4:25UNDER THE HOOD LOCKS
- 7:46DON'T ADD COLUMNS WITH A DEFAULT VALUE.
- 9:58UNDER THE HOOD TRANSACTIONS
- 17:32DON'T BACKFILL DATA INSIDE A TRANSACTION.
- 19:40DON'T MIX SCHEMA AND DATA CHANGES.
- 23:18DO ADD POSTGRES INDICES CONCURRENTLY.
- 23:44CASE STUDY AUDITS
- 26:23UNDER THE HOOD CONCURRENCY
- 29:24AUDITING OVERVIEW BUT ACCURATE THIS TIME
related talks
45mrails db:migrate:even_safer
30mPuny to Powerful PostgreSQL Rails Apps
33mPeaceful Django Migrations with Efe Öge
35mDatabase migrations without downtime
29mMigrating Data Quickly and Safely
33mDatabase Schema Migrations with Zero Downtime
37mCommon Possible Preventative Measures to Avoid Locking Issue in PostgreSQL
37mDatabase Schema Migrations with Zero Downtime