The Migration Plan Was Solving the Wrong Problem

Sat, 15 Aug 2026 00:00:00 +0000

The approved migration plan called for a fresh database schema. I wanted to keep the existing one. That disagreement wasn’t hidden in a difficult Go implementation; it was written into the planning package before the production port phase began.

I had approved that package for planning, not implementation. When I asked whether the existing migrations and schema would be faithfully replicated, the answer was no: the documents explicitly described a redesign. The plan could be internally consistent and still be the wrong plan for this engine.

A Migration Is a Production Change

Wed, 01 Mar 2017 00:00:00 +0000

We deployed an additive schema change which the database could execute without rewriting the table. On paper it was cheap. In production it waited indefinitely.

The statement needed an exclusive table lock. A long-running session already held a conflicting lock, so the migration queued. New application traffic then queued behind the migration. The column addition was cheap after lock acquisition; waiting to begin was the incident.

Another schema change looked cheap for the opposite reason: remove fields and tables which the application no longer read. The SQL was small, but the decision would erase financial history from data sets measured in tens of gigabytes. Neither change could be judged by reading the migration method alone.

Migrations on Brian Faust

The Migration Plan Was Solving the Wrong Problem

A Migration Is a Production Change