It's all nice and good but there is an additional problem the article doesn't mention: how do you handle "exceptional" (unplanned) cases in your database versio

It's all nice and good but there is an additional problem the article doesn't mention: how do you handle "exceptional" (unplanned) cases in your database version control? Sometimes you discover things don't work as you expected, or that there is a last-minute schema change you want to promote quickly to the production db. I find it hard to encompass these situations by modeling changes via forward/backward migrations (database schema diffs, like rails does). At my workplace we operate a large-ish web service in our own datacenters (airline reservations). We're very happy with the way we version code: we've one single branch where changes arrives all over the clock; every second day this branch is deployed in a "pre-production" platform. Every week we take one of those versions, fork a release branch out of it, and make all necessary adjustments, i.e. a bunch of cherrypicks (changes arrived late but needed quickly) and possibly backouts (we found a bug and have no time for a fix): a--b--c--d--e <--- what's in pre-prod \ b*--e' <--- what I want in prod b* = backout, e' = cherripick Now, I really really would like to do the same for our DDL (database schema changes). But backouts and cherrypicks just don't work if you're versioning migrations, because you have to deal with what's already in the prod db (conversely, when you deploy software you just trash the old binary alltogether and replace it with the new one): backouts, like b* above: you would hand to your DBA the sequence of patches a,b,c,b* ,e' which makes no sense because you're asking to apply migration b and its reverse b* (you should say "just skip b", but version control doesn't work like that) cherripicks, like e' above: good luck remembering, in two weeks from now, that you've already applied e' and don't need to apply e. At the end of the day, we -do- version our changes with forward/backward migrations, but we always end up managing backups and cherrypicks by sticking notes on the wall (or on the team wiki), which smells bad. I admit I never tried any of the popular solutions for database version control (liquibase, flyway) and I don't know how they work. But I feel the ideal solution would be to version the whole schema (not schema diffs), and have tools that at any given moment can compare the schema I have in my VCS and what is actually on the platform, and generate the necessary "migration" on the fly. EDIT: formatting