1. 29
  1. 11

    Renaming a column is admittedly the simplest possible migration

    Not sure what the motivation to rename a column in production is, especially a primary key. I figure you get to decide once whether your primary key columns are named id or thing_id and then you never change lest you go slightly batty. Protecting clients from fact table schema changes by using views and triggers is a certainly a viable technique but view migrations have annoyances of their own.

    And on the third hand, why not have maintenance downtime? Is the cost over time of your feature flags, client-server schema versioning, adding and removing views and triggers to let your clients keep running really cheaper than the cost of planning for a five minute outage during a change window? It depends on your line of work obviously but yknow…why not downtime, if you need it?

    1. 4

      Not needing downtime is better if it comes with a low cost.

      If you need downtime, that adds something to communicate or negotiate with every affected user, and the client if you are client facing. Changes that require less negotiation are generally good.

      Of course the negotiations might not need to exist, or you can schedule maintenence away from your active times. The cost then of being able to do zero downtime migrations becomes harder to justify, but not impossible. If it’s easy enough to keep the ability, why not do so?

    2. 2

      That’s the concept behind Reshape, a (Rust) binary doing migrations for you.

      1. 7

        Note: The author of the post is the author of Reshape..

      2. 2

        The search path hack is the crux of this. I don’t know of a good way to manage search paths for running applications though. Anyone have thoughts on this?