At this point I can barely imagine working with a relational database without using liquibase. It does take some getting used to, and there's a few ways you can

At this point I can barely imagine working with a relational database without using liquibase. It does take some getting used to, and there's a few ways you can get yourself a little bit stuck during development, like when you realize a change you've just applied is wrong, and you dive into the changelog or source files to fix it BEFORE you've asked liquibase to roll back the bad change. Then, when you finally remember to roll back the bad change, liquibase refuses because you've edited the change's definition, and it no longer corresponds to what was actually applied to the database. It's not a very big deal, and if you have more presence of mind than me you might learn not to trip yourself up in that particular way in the first place. In my job I really struggle with getting meaningful test data, and so having the ability to clone the live database and let liquibase roll forward with new changes from a dev branch, try things out, roll back, tweak things and roll forward again is very handy. Also if you're maintaining a large number of stored procedures, it's very handy to keep each of them in a separate file and reference them from your changelog something like: <sqlFile path="..." runOnChange="true"/> - the runOnChange property means that whenever the contents of the file is changed liquibase will automatically reload the procedure. (Though for example, postgres will complain if the change alters the type signature of a function.) I'd recommend using the XML config format (though JSON and YAML are also supported), and use an editor that understands XML schemas. Probably any of the free Jetbrains ones will, certainly PyCharm does. Load the XML schema definitions into the project settings, and you'll get syntax autocompletion and validation for your liquibase changelog files.