Database migrations, explained without the jargon

The version of this that works is simpler than the version most people imagine. Here is database migrations without the vocabulary that usually surrounds it.

Most development decisions are really maintenance decisions wearing a different hat. Doing this properly once is usually cheaper than doing it approximately three times.

The short version

Migrations should be reversible or provably safe. The teams that handle this well are rarely the ones with the biggest budgets. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. That sounds obvious written down. It is still the thing most often skipped.

Test them against a copy of real data volumes. The reasoning matters more than the rule, because the rule has exceptions. It rarely shows up as a line item, which is exactly why it slips.

What to do next

Backwards-compatible changes let you deploy without downtime. The reasoning matters more than the rule, because the rule has exceptions. Budget a little time for it every quarter and it never becomes a project of its own.

What this looks like day to day

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about database migrations before you move on:

• Someone can say what the current setup is without going to look
• Test them against a copy of real data volumes — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.