Can I rename a column or table while the old code is still deployed?
Rename or drop breaking the deploy window
Warning: this works, but blocks traffic or rewrites data at scale.
What happens
Between the migration running and the last old app instance stopping, old code still queries the old name. A rename or drop makes those queries error immediately, a partial outage that lasts exactly as long as your rollout.
Why it is dangerous on a populated table
It completes, but the time it holds its lock or rewrites rows scales with the table, and on a busy one that is long enough for traffic to queue.
Fires on
ALTER TABLE users RENAME COLUMN email TO email_address;The safe pattern
Expand/contract: add the new name alongside the old, have app code write both and read the new one, backfill in batches, then drop the old name a release after no deployed code references it. A rename becomes two additive steps that never break in-flight queries.
SET lock_timeout = '5s';
ALTER TABLE users ADD COLUMN email_address text;
-- dual-write both columns from the app, backfill in batches,
-- switch readers, then drop the old column a release laterFixtures
The rule ships with these files and the test suite runs them on every change: the first set must fire, the second must stay silent.
Fires (3)
DROP TABLE sessions;ALTER TABLE users RENAME COLUMN email TO email_address;ALTER TABLE users RENAME TO accounts;Stays silent (1)
ALTER INDEX idx_users_email RENAME TO idx_users_email_v2;How to check locally
This rule runs locally in the free CLI, or with the full corpus through the hosted service. No install, nothing leaves your machine:
npx bolvrk check migration.sql