Pimp My IDE / Garage Dispatch
Back to garage
September 26, 2026 | PostgreSQL / migrations / production locks

Your migration file does not know the traffic.

A SQL statement can parse cleanly and still wait behind another transaction, grab a stronger lock than expected, or hold the queue open inside a deployment wrapper. Review the statement and the live operating conditions.

The take. Migration safety is a claim about exact SQL, database version, table shape, lock timing, transaction behavior, and recovery. A green linter result covers only the inputs the linter actually received.
Load the migration lock gantry

A useful checker appeared at the right moment.

Safe Not Safe puts a PostgreSQL migration into a browser-based editor and asks for table size and transaction-wrapper context. The interface ships examples for risky and safer statements, plus views for problems, output, parse tree, and rule engine.[1] That is a better review surface than approving DDL because it looks familiar.

The tool also makes a point that generic SQL review often misses. The same statement can carry different operating risk on a small idle table and a hot multi-million-row table. Context belongs beside the statement.

A migration is not safe because the syntax looks boring. It is safe enough for one named production shape, under one measured stop policy.

The lock queue is part of the change.

PostgreSQL says most commands acquire locks automatically. Its strongest table lock, ACCESS EXCLUSIVE, conflicts with every table-level lock mode. The documentation also says only that mode blocks a plain SELECT.[2] The important question is not just which lock a statement needs. Ask how long it can wait to acquire that lock and how much work can queue behind it.

A migration wrapped in a transaction can turn a short statement into a long lock lifetime. A blocked migration can also become the head of a line. Put lock_timeout, statement_timeout, transaction scope, and an abort owner in the deployment packet. Defaults are not a stop policy.

Safer forms still have conditions.

PostgreSQL documents that a standard index build blocks writes until it finishes. CREATE INDEX CONCURRENTLY allows inserts, updates, and deletes to continue, but PostgreSQL calls out caveats and extra work for that mode.[3] "Concurrent" is not a universal pass stamp.

Strong Migrations catches operations it classifies as potentially dangerous and suggests safer forms. Its own test is concrete. The operation either blocks reads or writes for more than a few seconds after lock acquisition, or has a good chance of causing application errors.[4] That catches known patterns. It does not observe your current blockers, replica lag, application release order, or cancel path unless you supply or test them.

Make the review packet executable.

  1. Freeze the statement. Save the exact SQL and database version. Framework methods are not the final lock request.
  2. Set the wait budget. Record lock and statement timeouts. Name the person or automation allowed to abort.
  3. Describe production. Record table size, write rate, long transactions, replicas, and whether the migration runner wraps DDL in a transaction.
  4. Prove the exit. Rehearse cancel or rollback on a production-shaped copy. Save lock observations, duration, application errors, and recovery time.

Run the static checker before the deploy. Then run the operational drill. The checker finds known statement hazards. The drill tests the environment that will carry the statement.

Interactive makeover / migration review gantry

Migration lock gantry

Traditional purpose replaced: a green or red migration badge. Better version: clamp statement, wait budget, production shape, and exit proof onto one review packet. The result says what remains untested.

Lower each evidence clamp

Select a clamp only when the deployment packet contains that information. The native checkboxes own the state. The gantry is a teaching model, not database telemetry.

Migration review packet sections
PACKET EMPTY0 / 4 CLAMPS

Start with the emitted SQL.

A blank packet means the migration has not been described here. It does not mean the migration is blocked or safe.

StatementOPEN
Wait budgetOPEN
Production shapeOPEN
Exit proofOPEN

Completion means four packet sections were selected. Required values still need human review against current production evidence.

Print the migration review card

Replace every required marker. Attach real command output before approval. Selected sections describe packet structure only.

Sources read, not vibes

Open the source log
  1. Safe Not Safe, "Is my migration safe?", read September 26, 2026. Interactive PostgreSQL migration checker with table-size and transaction-wrapper inputs, examples, parse-tree output, and rule-engine output.
  2. PostgreSQL 18 documentation, "Explicit Locking". Authoritative table-lock modes, conflicts, automatic acquisition, and pg_locks reference.
  3. PostgreSQL 18 documentation, "CREATE INDEX". Standard and concurrent index-build behavior, write-lock difference, and documented caveats.
  4. ankane/strong_migrations. Open-source migration checks, dangerous-operation definition, safer patterns, and supported databases.
  5. Hacker News item 49854161. Exact discovery trail for Safe Not Safe. Comments were not used as technical evidence.

Source boundary. PostgreSQL documents command and lock behavior. Safe Not Safe and Strong Migrations apply rules to known patterns. Neither static tool can infer every live blocker, workload, deployment wrapper, or recovery result. The four-clamp gantry is Pimp My IDE's review method.