Regarding the thoughts on migrations, which I 100% agree with, one strategy for cutting down the steps in a migration is to make the application compatible with

Regarding the thoughts on migrations, which I 100% agree with, one strategy for cutting down the steps in a migration is to make the application compatible with the schema both before and after the migration. This can either be done by checking the migration sequence number, or by detecting the actual schema change. Using the author's example, where the migration involves a transition from an old table to a new table, you would make the application able to read/write using any combination of the tables. Then you can run your migration and/or move data. Later on, clean up the conditionals in the application code. --- And on a different topic: The Java SQL/database library, jOOQ [1] comes with a code generator that allows you to generate Java classes corresponding to your schema. This is pretty cool because it enables type-safe query building. It's a bit like connecting Java's type system to the database's type system. I find this to be really useful for ensuring correctness. And if you're taking the approach from the first half of my comment, you can generate code any versions of the schema you need in the application. [1] https://www.jooq.org/ https://www.jooq.org/ jOOQ is really cool for a lot of reasons. The code generator is just one piece of it. For example, it can be used to translate between different vendors' dialects.