Does Persistent support atomic rollback for destructive schema migrations

Short answer

No. Persistent’s runMigration runs each individual migration step in a transaction, but it does not treat an entire migration file (or a destructive change such as a column rename) as a single atomic unit. A rename is translated into a DROP COLUMN followed by an ADD COLUMN, and the generated DDL is not wrapped in a transaction. If the migration aborts mid‑way, the schema can be left in a partially altered state.

Confirmed behavior

• Additive changes (new tables, indexes, columns) are fully transactional – a failure rolls back automatically.
• Destructive changes (renames, drops) are emitted as separate DDL statements; Persistent does not generate reversible scripts.
• Backend matters: PostgreSQL supports transactional DDL, so you can manually wrap the destructive step in a withTransaction block to achieve atomicity. SQLite and many MySQL storage engines do not support transactional DDL, so even a manual transaction cannot protect you there.

Practical mitigation steps

1. Identify the target database – this determines whether a manual transaction can help.
2. Back up the database before applying any destructive migration in production.
3. Test on a staging copy – run the migration, then simulate a failure (e.g., throw an exception) to verify the schema state.
4. If using PostgreSQL, wrap the destructive change in a custom transaction:

   runMigration $ do
     withTransaction $ do
       -- manual DDL for rename
       execute_ "ALTER TABLE users RENAME COLUMN old_name TO new_name"
   

5. If using SQLite/MySQL or you need guaranteed reversibility, generate the migration SQL with an external tool (e.g., sql-migrate or flyway) that produces up/down scripts, then apply those scripts outside of Persistent.

Verification you can run locally

• Create a test DB, apply a rename migration via runMigration, then abort the Haskell process (or throw an exception) and inspect whether the old column still exists.
• On PostgreSQL, repeat the test with the withTransaction wrapper and confirm both DDL statements roll back.
• On SQLite/MySQL, repeat and observe that the rename persists despite the abort, confirming lack of atomicity.

One diagnostic detail that changes the recommendation

Which database backend are you targeting? If it’s PostgreSQL, a manual transaction can give you atomic rollback; if it’s SQLite or MySQL, you must rely on backups or an external migration framework.