在我回答问题之前的一个小更正.假设

A small correction, before I answer question. The assumption

Liquibase似乎具有Flyway的所有功能

Liquibase seems to have everything Flyway has

不正确.在解析SQL时，Flyway令人眼前一亮.您可以使用由本机工具生成的未修改的SQL文件，该文件包含各种复杂性，例如PL/SQL包和过程，MySQL分隔符更改，T-SQL，PostgreSQL过程等.使用Liquibase，您必须将这些拆分成单独的语句，在SQL文件中添加额外的注释，...

isn't correct. Flyway shines when it comes to parsing SQL. You can use unmodified SQL files generated by your native tools containing all kinds of complexity like PL/SQL packages and procedures, MySQL delimiter changes, T-SQL, PostgreSQL procedures, ... With Liquibase you would have to split these in individual statements, add extra comments to the SQL files, ...

能够原样使用SQL文件的好处是避免了锁定.您可以获取现有的SQL文件，以最少的投资开始使用Flyway，如果以后不再适合您的需求，请稍后移开. Liquibase并非如此.

The beauty of being able to use your SQL files as-is is that you avoid lock-in. You can take your existing SQL files, start using Flyway with minimal investment and moved away later if it doesn't suit your needs anymore. Not so with Liquibase.

迁移向下的问题(将其视为补偿性交易，而不是回滚)在理论上确实听起来不错，但实际上几乎不需要.请参见 https://flywaydb.org/documentation/faq#downgrade

Also the issue of down migrations (think of them as compensating transactions, not rollbacks) is really something that sounds great in theory, but that is almost never needed in practice. See https://flywaydb.org/documentation/faq#downgrade

但是，当涉及到使用一种或两种方法时，我当然同意SteveDonie(Liquibase团队成员)的观点，即仅使用一种方法而不是同时使用这两种方法几乎总是更好的选择.

However when it comes down to using one or both, I certainly agree with SteveDonie (Liquibase team member) that using just one instead of the both together is almost always the better choice.

免责声明:我是Flyway的创建者