TRUNCATE in a migration

Critical — this fails outright or takes production down.

What it catches

TRUNCATE deletes every row irreversibly, takes ACCESS EXCLUSIVE on the table, and cascades to referencing tables when asked. A migration that truncates in dev fixtures does the same to production data.

Fires on

TRUNCATE orders CASCADE;

Do this instead

Keep data removal out of schema history. Archive first, then delete in bounded batches from a job that commits per batch — reversible in review, resumable on failure, and never holding ACCESS EXCLUSIVE. If a table is genuinely scratch data, truncate it manually in a maintenance window with a backup taken, not from a migration.

-- From a job, not a migration — bounded batches, commit each:
--    DELETE FROM orders WHERE id IN (
--      SELECT id FROM orders WHERE created_at < '2024-01-01' LIMIT 5000);
-- loop until 0 rows deleted

Catch this before it ships

This rule runs locally in the free CLI — or with the full corpus through the hosted service: npx bolvrk check migration.sql

Browse all 69 rules

← BV012 BV014 →