Complexity of Database Migration Tools

“Database as Code – The Good, the Bad and the Ugly It took me a few minutes to really understand what you&#x27;re getting at, but I think I understand.<p>And Flyway can be used in conjunction with GitLab&#x2F;GitHub to achieve the same thing, but it&#x27;s still plagued with all of the issues you can probably imagine, especially if your DB doesn&#x27;t support transactional DDLs.<p>I agree about how these database migration (i hate this name) tools are starting to show their age, but when it comes to read&#x2F;write schemas there doesn&#x27;t seem to be many options.<p>If you&#x27;re wondering why I qualified the above statement with &quot;read&#x2F;write&quot;, there is an alternative way of managing read schemas that has a lot in common with any other sort of artifact management lifecycle that we have become accustomed to. Every source change that results in a CI&#x2F;CD activity leads to an entirely new instance of the schema being built out. Then it&#x27;s just a matter of hot swapping the new schema (`ALTER SCHEMA ACME SWAP WITH ACME_V2_0 RENAME TO ACME_V1_9_OLD`) or just having your consumers update their connection configurations to point to the new schema (schema=ACME_V2_0). Rollback is just unswap, or reverting your app&#x27;s connection config (or maybe the software artifact should be hard tied to the schema anyways?).<p>The whole process of using a migration tool to alter individual parts of a live schema one piece at a time, updating&#x2F;data, etc... and rollback if necessary, is extremely complex and an incredible nightmare to deal with, esp if these tools are in the hands of app developers with limited DBA experience.<p>Imagine that if instead of building new code artifacts (jar, zip, etc) we just resorted to taking the latest one, modifying it, and then saved it (overwrite). And then when you experience an issue and have to rollback, you have to undo everything mentioned above.”