MergeBrake
Prisma migration linter

A Prisma migration linter that checks the app code, not just SQL.

SQL-only migration linters are useful, but Prisma teams often break production at the boundary between schema and application code. MergeBrake scans the migration and the repository together before the PR merges.

SQL AST

Postgres-native parsing

libpg_query parses migrations, so comments and quoted identifiers are handled as SQL, not string matches.

Prisma mapping

Follow @map aliases

Database columns such as full_name are mapped back to fields such as fullName.

PR comment

One focused verdict

The GitHub Action posts a sticky SAFE / EXPAND_CONTRACT / BLOCK comment and updates it on every push.

Rules that matter for Prisma teams

  • ALTER TABLE ... DROP COLUMN with app-code impact.
  • ALTER TABLE ... RENAME COLUMN where old code still reads the old field.
  • ADD COLUMN ... NOT NULL without a safe rollout.
  • CREATE INDEX without CONCURRENTLY on existing tables.
  • Foreign keys, unique constraints, and primary keys added inline.
  • Contract-without-expand PRs that remove code references and drop schema together.

Why not only use a SQL linter?

SQL linting answers whether a migration is mechanically risky. MergeBrake adds the application question: if this migration ships, which files may still depend on the dropped or renamed symbol?