Stop dangerous DB migrations from merging.
MergeBrake is the pre-merge guard for Postgres + Prisma / Drizzle teams. It maps every DROP COLUMN, RENAME, or unsafe NOT NULL to the application code it would break — following Prisma @map and Drizzle pgTable aliases — and posts a sticky review comment that updates on every push.
$ npx mergebrake scan "prisma/migrations/**/migration.sql" MergeBrake — schema impact guard ──────────────────────────────────────────────── Verdict: 🔴 BLOCK — data loss or downtime risk Risk score: 150 ORM stack: prisma Dialect: postgres AI-PR detected (scrutiny ×3.00): Claude #1 CRITICAL DROP COLUMN users.full_name is destructive prisma/migrations/20260511_drop_full_name/migration.sql:3 App-code impact (3 references): • src/api/profile.ts:9 name: u.fullName, • src/api/users.ts:11 full_name: true, • src/api/users.ts:18 SELECT id, email, full_name FROM users Safe rollout: [expand] Deploy app code that no longer reads full_name. [migrate-data] Archive users.full_name (optional). [contract] ALTER TABLE users DROP COLUMN full_name;
The coordination problem nobody flags
SQL-only linters can flag locks and destructive DDL. Generic AI code reviewers can comment on style. The failure that actually hurts teams sits in between — and that gap is exactly where Claude, Cursor, and Codex put their riskiest PRs.
-
Step 1
An agent generates a migration that drops or renames a column.
-
Step 2
Your ORM maps that column to a different field name in TypeScript. A grep for the SQL name finds nothing.
-
Step 3
Old replicas, jobs, or API serializers still read it during the rollout window.
-
Step 4
The PR looks mechanically plausible. Review approves. Production explodes 20 minutes after merge.
How MergeBrake closes the gap
One install. Every PR that touches your schema gets a sticky review comment in under a minute.
Schema-aware parser
Reads Prisma @map, Drizzle column aliases, Knex / Sequelize / TypeORM queryRunner.query() blocks. No regex theatre — it knows User.displayName refers to users.full_name.
App-code impact map
Greps 13 languages (TypeScript, Python, Go, Ruby, Java, PHP, raw SQL …) for every variant of the symbol the migration touches. Skips comments and migration history.
Deploy-order check
Compares the head branch to a base checkout. Flags the dangerous contract-without-expand pattern: cleanup + destructive migration shipped in one deploy.
AI-PR scrutiny
Detects Co-Authored-By: Claude, Cursor, Codex, Copilot, Aider, Devin, and raises the risk-score multiplier 2.5–3×. Borderline-safe migrations become a BLOCK.
What reviewers actually see on the PR
One sticky comment. Updates on every push. Quotable, expandable, paste-able into Slack.
MergeBrake — schema impact guard
Verdict: 🔴 BLOCK — data loss or downtime risk · Risk score: 150
- • ORM stack:
prisma - • Dialect:
postgres - • 🤖 AI-generated PR detected (scrutiny ×3.00): Claude
1. 🔴 DROP COLUMN users.full_name is destructive
prisma/migrations/20260511_drop_full_name/migration.sql:3
· rule destructive/drop-column
This migration drops column full_name from
users. Existing row data will be permanently
deleted, and any application code still reading or writing the
column will start failing the moment this deploys. MergeBrake
recommends an expand/contract rollout in at least two deploys.
App-code impact
src/api/profile.ts:9 name: u.fullName, src/api/users.ts:11 full_name: true, src/api/users.ts:18 return prisma.$queryRaw`SELECT id, email, full_name FROM users …`
Expand / contract recipe
[expand] Deploy app code that no longer reads or writes
full_name.
Search the cross-references above and remove queries, ORM selects, serializers, and API responses that still reference the column.
[migrate-data] Optional: archive
users.full_name before destruction.
CREATE TABLE archive_users_full_name AS SELECT id, full_name FROM users;
[contract] After one release cycle, drop the column.
ALTER TABLE users DROP COLUMN full_name;
Scanned in 30 ms by MergeBrake. Configure
Install in 60 seconds
Drop one workflow file. MergeBrake runs on every PR, posts a sticky comment, and fails the check when the verdict matches your policy.
.github/workflows/mergebrake.yml
name: MergeBrake
on:
pull_request:
paths:
- 'prisma/**'
- 'drizzle/**'
- 'migrations/**'
- 'src/**'
permissions:
contents: read
pull-requests: write
jobs:
schema-impact:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: mergebrake/mergebrake@v0
with:
fail-on: BLOCK
Run it locally
# Scan an existing migration set npx mergebrake scan \ "prisma/migrations/**/migration.sql" # Pipe a JSON report into the sticky-comment poster npx mergebrake scan ... --format json \ | npx mergebrake comment --from-stdin \ --token $GITHUB_TOKEN \ --repo octo/repo --pr 123 # Fail CI only on BLOCK; EXPAND_CONTRACT still gets a comment npx mergebrake scan ... --fail-on BLOCK
Works on GitHub-hosted runners and self-hosted runners. Requires
Node 20+. The action calls npx mergebrake@latest by
default; pin the version with the mergebrake-version
input for reproducible CI.
We ran MergeBrake on real Postgres repos. Here's what it found.
Across the full migration history of three popular Postgres + Prisma open-source projects, the default ruleset flagged 2,339 risky patterns in 1,066 migrations — without one false positive on a SQL comment.
add-foreign-key-without-not-valid (114),
create-index-non-concurrent (123),
drop-constraint (60).
None of these projects are "doing migrations wrong" — they ship at the speed real teams ship. The findings are the kind of pre-merge warnings their reviewers would have seen with MergeBrake wired into their PR workflow. Full case studies →
What MergeBrake does that linters and AI reviewers don't
| Capability | SQL linters | AI code reviewers | MergeBrake |
|---|---|---|---|
| Destructive DDL detection | ✓ | — | ✓ |
| Lock mode & downtime checks | ✓ | — | ✓ |
ORM-aware impact (@map, Drizzle aliases)
|
— | — | ✓ |
| App-code references for every change | — | partial | ✓ |
| Deploy-order: contract-without-expand | — | — | ✓ |
| AI-PR scrutiny multiplier | — | — | ✓ |
| Sticky PR comment that updates | — | ✓ | ✓ |
Comparison reflects publicly available behaviour of common open source migration linters and AI code review tools as of May 2026. Open a PR if you spot something out of date.
Paid founder pilot
DB PR Risk Audit + Drift Check.
The analyzer is free. The paid pilot is hands-on help for teams that want one production workflow reviewed, installed, and tuned without turning migration safety into a platform project.
Historical audit
Full migration scan, top risky PRs, app-code impact, and the rollout policy your team should start with.
CI setup
GitHub Action installed or PR-ready workflow supplied, plus a
tuned .mergebrake.yml for Prisma or Drizzle.
Optional drift check
If you can share a safe schema snapshot or non-production DB, we review Prisma migration-history drift and write a manual recovery plan.
Money-back filter
Refund if the audit does not surface at least one useful migration risk or workflow improvement.
Built for B2B SaaS teams with 3-30 developers, GitHub Actions, Postgres, and Prisma or Drizzle. No production DB credentials needed for the core audit.
Ask for a founder pilotThe OSS CLI and GitHub Action stay MIT-licensed and free.
FAQ
Which databases and ORMs are supported?
MergeBrake parses migrations for Postgres, MySQL, and SQLite, and detects schema mappings from Prisma, Drizzle, Knex, Sequelize, TypeORM, and plain SQL files. Postgres has the most rules today; MySQL and SQLite ship with the destructive/rename/notnull family, with dialect-specific lock-mode rules planned after the Postgres launch.
Is MergeBrake open source?
The CLI and GitHub Action are MIT-licensed and free. The paid offer is a EUR 500 founder pilot: historical migration audit, CI setup, Prisma/Drizzle rule tuning, and an optional drift check when the team can share a safe schema snapshot.
Does the action need access to my production database?
No. MergeBrake never connects to your database. It only reads files inside the PR checkout and (optionally) a base-branch checkout for deploy-order analysis. The only network call it makes is to GitHub's REST API when posting the sticky PR comment.
What permissions does the workflow need?
contents: read for the checkout and
pull-requests: write for the sticky comment. If
pull-requests: write isn't available — for example
on forked PRs — MergeBrake still emits inline annotations and
respects the fail-on policy.
How is this different from CodeRabbit / Greptile / Squawk / pgfence?
MergeBrake isn't a general AI code reviewer and isn't a
SQL-only linter. The wedge is the moment when an agent removes
users.full_name from a Prisma or Drizzle schema and
the application still reads it via
User.fullName, raw SQL, an API serializer, or a
background job. We follow the rename across surfaces and refuse
the merge until the rollout is sequenced correctly.
How fast is it?
Median scan time on the bundled examples is well under 50 ms. On a real repo with ~500 source files, expect ~1–3 seconds for the cross-reference step. The action runs entirely in the workflow runner — no remote inference, no LLM cost per PR.
Stop reviewing schema-impact PRs by hand.
Install the action today, or use the founder pilot if you want the first migration-risk audit and CI setup handled with you.