MySQL and MSSQL migration safety when Knex cannot wrap DDL in a transaction

Goal: ensure safe recovery from a failed Knex migrate:latest on MySQL or MSSQL where DDL cannot be rolled back automatically. Constraints: Knex only records a migration after its up promise resolves, so a mid‑file failure leaves the schema ahead of the knex_migrations entry and does not invoke the down function; recovery therefore depends on external backups or a manually written compensating down script.

Uncertainty: should each migration explicitly declare transaction: false on these dialects to make the lack of automatic rollback visible, or is it safer to keep the default transaction wrapping and treat any partial failure as requiring a backup‑restore or a hand‑crafted down script that can be reapplied? Questions: Is it advisable to mark migrations with transaction: false on MySQL/MSSQL to expose failure semantics? Should teams rely on a pre‑migration backup and a manual down script as the only reliable recovery path? Can a migration be written to be idempotent and safe to re‑run after a partial failure without invoking down?