When is it safe to DROP COLUMN during a rolling deploy?
DROP COLUMN destroying data inside the deploy window
Warning: this works, but blocks traffic or rewrites data at scale.
What happens
Dropping a column destroys its data irreversibly, and any app instance deployed before the migration still selects or writes the column until the rollout completes, those queries fail immediately. The safe order is: stop reading it in code, deploy, then drop one release later.
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 DROP COLUMN legacy_flags;The safe pattern
Contract in two releases: release N stops every read and write of the column in app code and fully deploys; release N+1 drops the column. The drop itself is then metadata-only and instant, guard it with lock_timeout and it is safe.
-- Release N: remove every app reference to the column, deploy fully.
-- Release N+1 (metadata-only, instant once nothing reads it):
SET lock_timeout = '5s';
-- ALTER TABLE users DROP COLUMN legacy_flags;Fixtures
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 (1)
ALTER TABLE users DROP COLUMN legacy_flags;Stays silent (1)
CREATE TABLE scratch (a text, b text);
ALTER TABLE scratch DROP COLUMN b;How to check locally
This rule runs in the hosted service on Startup and above: add --remote with a team token, or use the GitHub Action. No install, nothing leaves your machine:
npx bolvrk check migration.sql --remote