Michael Widenius added a comment - 2014-05-16 12:46 - edited The following link shows which databases supports transactional DDL:s and how: https://wiki.postgresql.org/wiki/Transactional_DDL_in_PostgreSQL:_A_Competitive_Analysis Ideally we would like to have transactional DDL for CREATE TABLE ALTER TABLE DROP TABLE CREATE TABLE: Reasonable easy to do for all storage engines. ALTER TABLE Possible to do for any transactional engine that supports online ALTER TABLE Changes that doesn't affect storage format can be done for all storage engines. DROP TABLE Probably the hardest to do. We may be want to leave DROP TABLE as the last step. That said, I think that we should initially do transactional DDL:s only for transactional engines (XtraDB, InnoDB and TokuDB) Internal change: Have version number in the table cache and table share Have a table cache for each THD (to be able to store table versions that is only visible for one user) Do necessary changes in InnoDB to be able to have many versions (any number) of the same table Delay replacing the new created table in ALTER TABLE until commit is done. (This can be very tricky if you do several ALTER TABLE:s on the same table that is use by another transaction; We could consider changing the original table to read only while the transaction is running to simplify this case) We need to have a sql-mode that does autocommit before and after CREATE, ALTER TABLE and DROP TABLE to ensure that applications running in not autocommit mode will work as before. Example of things that one should be able to do: BEGIN CREATE TABLE t1 (a int) ALTER TABLE t1 add column b int; ALTER TABLE t1 add column c int; ROLLBACK; This should roll back all changes and the creation of table t1;