How does this compare to Entity Framework (for dotnet) migrations or sqitch/liquibase.

I get the declarative nature of this, but migration of schemas is not purely declarative, particular on large production databases. An ideal schema manager would understand the costs of particular migrations (perhaps by using the table stats and EXPLAIN) and apply that back to the migration strategies so that downtime is minimized/eliminated.

Adding or remove columns or indexes can trigger major database table scans and other problems, especially when partitioning conditions change.