DEV Community

Joaquin Orozco
Joaquin Orozco

Posted on

Catch risky SQL migrations in pull requests before they lock production

#postgres #devops #github #database

Most migration incidents aren't exotic: a DROP COLUMN that an old app instance still reads, an
ALTER COLUMN ... SET NOT NULL that scans a 200-million-row table, a CREATE INDEX without
CONCURRENTLY that blocks writes for minutes, an UPDATE that forgot its WHERE.

I build MigrationGuard, a JetBrains plugin that reviews migration SQL as you write it, and I've just
released a free GitHub Action that runs the same checks on every pull request.

Add it to a repository 

name: Migrations
on: pull_request
jobs:
  migrationguard:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0
      - uses: jog16889/migrationguard-action@v1
Enter fullscreen mode Exit fullscreen mode

It only looks at the .sql files changed in the pull request, annotates the risky lines, explains a safer
approach for each one and fails the job on high or critical risks. Nothing leaves the runner: no database
connection, no SQL uploaded.

What it flags (free)

  • DROP TABLE / DROP COLUMN and TRUNCATE
  • UPDATE / DELETE without WHERE
  • Column type changes that rewrite or truncate data
  • PostgreSQL CREATE INDEX without CONCURRENTLY

The dialect (PostgreSQL or MySQL) is inferred from the file, your Spring/Flyway/Liquibase config,
docker-compose or your JDBC driver dependency; you can pin it in .migrationguard.yml.

In the IDE

The plugin (IntelliJ IDEA Ultimate, DataGrip) shows the same findings while you type. Its Pro edition adds
rolling-deploy and locking rules (unsafe NOT NULL, volatile defaults, renames, constraint changes, MySQL
table rebuilds), a whole-project audit and an audit of only the migrations changed in your branch. There's a
7-day free trial.

Feedback welcome — especially false positives from real migrations.

Top comments (0)