MergeBrake
Postgres migration guide

Use CREATE INDEX CONCURRENTLY before production learns about locks.

A normal Postgres CREATE INDEX can take locks that block writes on busy tables. In pull requests, this often looks harmless because the SQL is short and ORM-generated.

The unsafe migration

CREATE INDEX "orders_created_at_idx"
  ON "orders" ("created_at");

On a small local database this finishes instantly. On a large production table, the same migration may hold locks long enough to turn a safe deploy into an incident.

The safer rollout

CREATE INDEX CONCURRENTLY "orders_created_at_idx"
  ON "orders" ("created_at");

Concurrent index creation avoids the most disruptive lock pattern, but it also means the migration cannot be wrapped the same way as a normal transactional migration. Your deploy pipeline must support that shape explicitly.

What MergeBrake checks

  • Flags CREATE INDEX without CONCURRENTLY.
  • Escalates non-concurrent unique indexes because they also enforce an app contract.
  • Demotes fresh-table indexes when the table is created in the same migration block.
  • Keeps low-value historical noise out of the main PR comment.