There is this new trend where some developers are saying if they want to see what the database looks like when using a migration strategy then the declarative strategy is better because you can look at a single file (schema) to see what the database looks like.
Migrations can contain more than table schemas
I find the single file argument to be false because a database contains more than table schemas and most of the declarative migration tools mainly cater for database table schemas. But what about functions, views. row level security (RLS) policies and even custom enum types? these normally don’t get catered for in an easy to manage way with these declarative migration tools.
Even outside of this I would still say the best way to know what your database looks like at any given point in time is to check the database itself because the schema file for the migration tool could be out of sync as you might not have ran the diff for the latest change as yet.
Too many files in the migration directory
There are arguments like there are too many files in the migration directory. Yes this can become unweilding after a while, especially in huge projects where they have like 100s of migration files, but good migration tools allows you to squash these into a single file. I especially like the Laraval approach to this, they have a --prune command that you pass to the migration tool on the CLI and it does the squashing for you.