The existing ALTER TABLE editor in the GUI can be extended to also generate the inverse ALTER TABLE operation. These inverse operations would then be stored and tracked by MaxScale, possibly by storing them in the database itself. The GUI can then provide a reversible history of a particular table by fetching the stored changes.

A reversion of a change is done by executing the inverse operations until the given version is reached. These "rollbacks" would then be recorded by swapping the operations around and incrementing a version counter, similar to how git revert creates a new commit for each reverted commit.

There are limitations in some operations that cannot be reverted without losing data. An obvious example of this is DROP COLUMN: you can't revert this and regain the lost data. Doing this would require support in MariaDB itself and is outside the scope of this issue.

Old description:

At configurable times (or before ALTER, CREATE OR REPLACE, DROP statements are executed), Maxscale should snapshot (dump) all DDL.

Schema time machine could allow for versioning of schema based on date or when changes are made and the gui should allow browsing by these versions and provide reversion scripts.

CLI could allow browsing with a git CLI or perhaps with a mariadb client type of interface.