Does Nimble provide atomic rollback for non-PostgreSQL migrations?

Nimble is a Go-based database migration tool that records applied migrations in a dedicated table and supports separate up and down scripts per migration. The goal is to understand rollback safety after a schema change when the same migration is run on different database dialects.

Constraints and current behavior

Atomicity is not enforced uniformly across dialects. PostgreSQL migrations are run inside a transaction, while MySQL and SQLite execute statements individually, which exposes the database to partial application if a statement fails. The tool provides up and down scripts but does not include a built-in verifier that a down migration truly reverses every change made by its up counterpart, leaving reversibility to manual review.

Documentation is sparse and version-specific, and rollback safety depends heavily on the underlying database’s transaction capabilities. An unresolved design decision is whether Nimble should automatically wrap all migrations in a transaction on supported databases; current releases enable this behavior only for PostgreSQL, leaving rollback safety uncertain on other systems.

Does Nimble wrap a multi-statement up migration in a single transaction on MySQL and SQLite? How is a partial failure handled mid-migration on those dialects with respect to the migration table and schema state? Is there a documented guarantee that a down migration will fully reverse the up changes without additional verification?