> It's nice to not have to fully reset your schema every time you test a migration file locally In terms of dev flow, this is only a problem with imperative mi

> It's nice to not have to fully reset your schema every time you test a migration file locally In terms of dev flow, this is only a problem with imperative migration systems. Declarative schema management tools solve it by being able to transition any live database state into the desired state, which is expressed by a repo of CREATE statements. If something fails, you fix the bad CREATE and run the tool again, and it effectively picks up where it left off. And well-designed declarative tools catch many problems pre-flight anyway by running a suite of linters, running the emitted SQL statements in a sandbox first, etc. If the tool's diff returns clean, you know your schema is in the right state on the DB. Ironically, lack of transactional DDL actually makes declarative schema management more straightforward in MySQL/MariaDB: you can't mix DDL and DML there anyway, so it's more natural to handle schema changes vs data migrations using different tools/pipelines.