Database migrations for small teams

Every audit we run turns up some version of this. Most advice about database migrations assumes a team that does not exist at your size. Here is the version that does not.

The question is rarely whether something can be built, but what it costs to keep running afterwards. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

What to keep

Migrations should be reversible or provably safe. Small and consistent beats large and occasional here. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. It is worth being explicit about, because assumptions differ quietly.

How we handle it

Backwards-compatible changes let you deploy without downtime. In practice this is a scheduling problem more than a technical one. Assume whoever inherits this will have half your context and none of your patience.

How to tell if yours is fine

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about database migrations before you move on:

• Someone can say what the current setup is without going to look
• Backwards-compatible changes let you deploy without downtime — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.