The migration engine is unsafe to use with MySQL
As you might know, a database migration is really just a series of small SQL scripts executed in order to change the database schema. Currently, the migration engine executes a migration by first opening a transaction, then executing all the migration scripts in order, and finally committing the transaction. If an error occurs in any of the scripts, the whole migration is rolled-back, restoring the database as it was before the migration started.
While this works as expected for SQLite & PostgreSQL databases, it does not for MySQL based databases (which are also officially supported). The reason is that, in the MySQL dialect, a number of statements cause an implicit COMMIT when executed (the full list of those statements can be found here.
Not only does this means that those statements cannot be rolled-back, but neither can the statements before it (since those have already been committed by the implicit commit), or after it (since those are no longer being executed in a transaction). This behavior makes migrating a MySQL database very dangerous because if an error occurs during the migration, the engine might not be able to restore the database as it was before, potentially leaving it in an usable state.
Unfortunately, as far as I can see, the only way to fix this problem would be to completely change the behavior of the migration engine.
First, the engine should no longer execute the whole migration inside a single transaction. This means that each script should be executed in a separate transaction, with a commit at the end. The consequence of that change is that restoring the database is case of error becomes more complicated, because the engine will only be able to roll back the current script. All the previously executed (an already committed) scripts of the migration will have to be reversed using the downgrade mechanism.
Second, to prevent those implicit commits from affecting the other statements, each of the statements with an implicit commit will have to be moved into a separate script with only that statement in it. This means that a lot of the exiting migration scripts will have to be split into smaller scripts to isolate those statements.
All in all, those changes will take a lot of time to implement, so in the meantime, I suggest we strongly discourage using a MySQL-based database with the gateway.