I think it is fair criticism that this adds complexity. However, I do have a couple of counter-arguments: In order to avoid downtime and locking, you generally

I think it is fair criticism that this adds complexity. However, I do have a couple of counter-arguments: In order to avoid downtime and locking, you generally need multiple steps (e.g. some variation of add another column, backfill the data, remove previous column). You can codify this in long guidebooks on how to do schema changes (for example this one from gitlab [1]). You also need to orchestrate your app deployments in between those steps, and you often need to have some backwards compatibility code. This is all fine but: 1. it slows you down and 2. it's manual and error prone. With pgroll, the process is always the same (start pgroll migration, deploy code, complete/rollback migration) so the team can exercise it often. Second, while any software has bugs, it's worth noting that the main reason roll-ing back is quick and safe with pgroll is that it only has to drop views and any hidden columns. While the physical schema is changed, it is in a backwards compatible way until with complete the migration, so you can always skip the views if you have to bypass whatever pgroll is doing. [1]: https://docs.gitlab.com/ee/development/migration_style_guide.html#choose-an-appropriate-migration-type https://docs.gitlab.com/ee/development/migration_style_guide...