For your index example, why not just do: create index new [..] drop index old; At every point, there's always an index to use. We usually have to split re

For your index example, why not just do: create index new [..] drop index old; At every point, there's always an index to use. We usually have to split releases into several "subreleases": Release #1 (automatic migration step) - alter the table - add a new index which uses new columns (etc.) (code release step) - new code goes live and starts using the new index Release #2 (we call it "post release") - remove the old unused index Automation, CI/CD help here. Yeah, it's somewhat error prone, but you usually get used to it. Not saying it's perfect, but manageable. In any case, you can never make both SQL migration and code release atomic (if you use rolling updates with zero downtime) so you already have to split into such subreleases anyway.