[axelfontaine]

Flyway author here.

Besides supporting many more databases, Flyway's parser is also much more robust with support for all kinds of database specific things like changing delimiters with MySQL, Oracle PL/SQL, PotsgreSQL COPY FROM STDIN, T-SQL, ...

And you can use truly plain SQL files like the ones generated from your DB's dump tool as a starting point, no special comments required.

(And of course you also have things like repeatable migrations, Java-based migrations (great for complex data transformations), API and build tool integration, ...)

[ojiikun]

All due respect to someone who has created a tool that does genuinely save me some work when deploying, but I can't internalise calling flyway a "migration" tool when failed deltas require such catastrophic manual cleanup. One typo or semantic error in a file and I get a corrupted stack that requires me to edit not only the file but the metadata table. I have started double-testing deployments to mitigate the awfulness, but are there any plans to ever make failed changes more graceful?

[axelfontaine]

No need to ever manually edit the metadata table. That what Flyway's repair command is for.

However if failed migrations are a big concern for you, do yourself a favor and consider moving to a database that offers proper DDL transactions like PostgreSQL, SQL Server or DB2. Flyway runs every migration inside a transaction and this way changes become truly atomic without any sneaky implicit commits (I'm looking at you Oracle and MySQL).