Most schema changes are safe; a few take locks that stop every query on a busy table. The expand-and-contract pattern for renames and type changes, the Postgres operations to treat with care (indexes, constraints, column rewrites), lock timeouts, and why the migration and the deploy must be separate steps.
During a deploy, old and new versions of your code run at the same time against one database. Every schema change must work with both. That rule, more than any tool, is what makes migrations safe.
Expand: add the new column or table alongside the old one. Old code ignores it.
Deploy code that writes to both and reads from the old.
Backfill existing rows in batches.
Deploy code that reads from the new.
Contract: once nothing uses the old column, drop it in a later release.
Renaming a column in one step breaks whichever code version expects the other name. Expand and contract turns it into several safe steps.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Run migrations as their own step before the code deploy, not on application boot across many instances.
Generate migrations with your ORM's tool and review the SQL it produced.
Test them against a copy of production-sized data; a migration that takes 50 ms on a test database can take an hour on the real one.
Take a snapshot before anything destructive.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
Safe Deploys for a Small Team: Feature Flags, Canaries and a Rollback You Have Practised
Shipping often is safer than shipping rarely, if each change is small and easy to undo. How feature flags separate deploying code from releasing features, how canary and blue/green deploys limit the blast radius, and the rollback habits that make a bad deploy a five-minute event.
Read
Timeouts, Retries and Idempotency: The HTTP Habits That Stop Double Charges
Every network call ends in success, failure or "we don't know". The third causes duplicate orders, double charges and stuck jobs. How status codes, timeouts, retries with backoff and idempotency keys fit together, with the limits on API Gateway and Lambda.
Read
As of October 26, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.