MergeBrake
Public catalog · regenerated on every release

Hall of Findings.

We ran MergeBrake on the full migration history of three popular Postgres + Prisma open-source projects. 2,339 risky patterns across 1,066 migrations. This is the catalog of what MergeBrake catches — every finding here would have been a sticky PR comment, with the exact application-code references it could have broken.

None of these projects are "doing migrations wrong." They ship at the speed real teams ship. These are the kind of pre-merge warnings their reviewers would have seen with MergeBrake wired into their workflow.

360
Critical
Data loss or table-wide downtime risk.
1,434
High
App-level breakage or long blocking locks.
388
Medium
Query-plan regression or contract relaxation.
157
Low
Style or convention issues worth flagging.

What gets flagged most

The default emitter of every modern ORM produces locking patterns most teams treat as "fine until production says otherwise." The two patterns at the top of this chart account for 48% of all findings.

locking/add-foreign-key-without-not-valid 624
locking/create-index-non-concurrent 499
destructive/drop-constraint 258
destructive/drop-column 244
locking/add-not-null-without-default 146
destructive/drop-table 116
safety/alter-enum-add-value 110
destructive/drop-index 98
safety/drop-not-null 53
locking/set-not-null 52
locking/alter-column-type 35
safety/drop-default 34
destructive/rename-column 27
safety/update-without-where 19
safety/create-table-without-primary-key 13
locking/add-primary-key 6
locking/add-check-without-not-valid 3
safety/set-default-volatile 2

The three riskiest migrations in the dataset

Each of these is a single PR that drops or rewrites enough structure that a careful reviewer would want a rollout plan. Click through to the actual SQL on GitHub — it's all public.

Risk score 4,426 · 268 findings

trigger.dev — schema redesign for new system

View on GitHub →

A single migration that drops 30+ tables, 18 columns, and rebuilds most of the application's data model in one transaction. Several production deploys' worth of expand/contract sequencing collapsed into one PR. The riskiest single SQL file in the entire dogfood corpus.

destructive/drop-table destructive/drop-column destructive/drop-constraint locking/add-foreign-key-without-not-valid locking/create-index-non-concurrent

What MergeBrake would have done: BLOCK verdict, force a split into expand-only and contract-only PRs, and surface every Prisma model field that would silently disappear from the TypeScript types post-merge.

Risk score 2,019 · 101 findings

documenso — add organisations

View on GitHub →

"Add organisations" sounds expand-only. In practice it drops pre-existing columns, restructures the team/user relationship, and adds dozens of foreign keys validated inline. On a busy Postgres, the inline FK validation alone can block writes for seconds-to-minutes on the referenced tables.

destructive/drop-column destructive/drop-table destructive/drop-constraint locking/add-foreign-key-without-not-valid locking/add-primary-key

What MergeBrake would have done: BLOCK verdict, suggest rewriting the FK additions with ADD CONSTRAINT ... NOT VALID + a follow-up VALIDATE CONSTRAINT, and produce app-code impact for the dropped columns.

Risk score 1,300+ · contract-without-expand

formbricks — remove deprecated fields and tables

View on GitHub →

Textbook contract-without-expand: a cleanup PR that drops 12 columns, 3 tables, removes enum values, and ships in a single deploy. The risk isn't whether the SQL is correct — it is whether every replica, background job, and stale browser tab has already stopped reading these fields. With Prisma's @map indirection, a plain grep would miss several of the affected app references.

destructive/drop-column destructive/drop-table destructive/rename-column safety/alter-enum-add-value

What MergeBrake would have done: BLOCK verdict, list every Prisma @map-resolved app reference still in the base branch, and suggest splitting the cleanup into expand (remove app references) → wait one release → contract (drop columns) PRs.

How we ran this

  • Three public Postgres + Prisma projects, all OSI-licensed: documenso, trigger.dev, formbricks.
  • Sparse-checkout pinned to a specific commit per repo so the numbers are reproducible. Commit hashes are in the dogfood folder.
  • Default ruleset, no .mergebrake.yml, no path filters. The same configuration any team gets on day 1.
  • Findings are not bugs in the projects. Each one is a point in time where, on a modern PR with the same migration, a reviewer would want a conversation before merging.
  • MergeBrake never connected to a database. Everything you see here came from reading SQL files and TypeScript source.

Want the same report on your repo?

Drop the GitHub Action into your workflow. The first PR you ship after merging it is the first one MergeBrake comments on.

Install the GitHub Action Become a design partner