Postgres migration safety checks
Locks that block writes, full-table rewrites, constraints that fail only on populated tables, destructive operations, replication hazards, column-type traps, credentials written into the migration.
A migration that parses is not a migration that is safe. Postgres will happily accept ALTER TABLE … ADD COLUMN … NOT NULL without a default and fail it at run time on the first populated table, or take an ACCESS EXCLUSIVE lock for the length of a rewrite while every write queues behind it. The safety rules — the BV family — catch the statements that parse fine and take production down.
The families: locks that block reads or writes; full-table rewrites; constraints and NOT NULL that scan or fail on populated tables; destructive operations (DROP, TRUNCATE, DROP OWNED, REINDEX DATABASE, ALTER SYSTEM); replication hazards; column-type traps; and the credential rules. Each finding names what breaks, why, and the safe form to use instead.
What it does not claim
Rules fire on what they can prove from the SQL and, when connected, from the catalogs. A rule that cannot prove a claim stays silent. No rule set catches everything; the rule reference lists exactly what each rule looks for, and the report always says which rules ran.
The CLI is open source and needs no account: npx bolvrk check migration.sql
Also in Deterministic rule engine
- Real parse-tree analysis
- Severity taxonomy
- Evidence-backed rules
- False-positive discipline
- Fuzz-tested boundaries
- A corpus of 69 rules
- Credential rules: no secret ever reaches the repo
- Secret scanning for any file: bolvrk secrets
- Performance rules: indexing and query health
- Query verification: bolvrk explain