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.
The bigger problem is that data can be part of a migration. A diff is far too rudimentary.
If I split a Fullname into FirstName and LastName, a diff will only tell half of the story. In EF Core, you will adjust an Up and a Down generated method to make the change reversible, plus you deal with data transformation there.
So I would love to know how people handle that without an explicit notion of migrations.