My company is an Oracle shop with a large (1300 pkgs, 350k LOC, 1700 triggers) PL/SQL-based app. Source is currently managed in SVN and a Python script is used to package source changes and generate a deployment script. Unfortunately the script intertwines source code merging with generation of the deployment script which sometimes forces large remerging exercises. We are planning on splitting source code management and building of the deploy package/script, and will take that opportunity to move to Git. We're assessing Flyway/Liquibase.
Additionally multiple long-running (8-12mth+) projects are run in parallel, each with multiple developers. Sometimes the order of deployment of a pair of projects swaps late.
From a fair bit of reading it seems that, to generalise, most proponents of Flyway/Liquibase are Java oriented people/apps that have DDL-centric apps with minimal DML. Those two tools, and others, seem well suited to that. But where most development is in PL/SQL, triggers (rightly or wrongly) and views then from what I can tell there is scripting development required to facilitate the use of those tools, particularly when a source code repository is used. Back-outs of DML are not directly handled by those tools so scripting is needed (DB restorepoints are a last resort). My assessment so far is that given scripting is needed to make tools those effective then extending that scripting to cater for what Flyway/Liquibase offers is a "small" step. Put another way, those tools don't solve enough of the specific problems we face and are therefore more overhead than value.