Can Grails database-migration rollback safely reverse schema changes across multiple datasources when DDL is non-transactional?

Question

In a Grails application that uses the database-migration plugin, schema evolution is tracked through ordered Liquibase changesets. The plugin supports explicit rollback blocks, but rollback safety depends on whether the underlying database treats DDL as transactional. Many storage engines auto-commit DDL, so a failed rollback can leave the schema in an intermediate state.

GORM runtime transactions such as withNewTransaction or TransactionService wrap DML only. Schema modifications made by Hibernate's hbm2ddl.auto at startup occur outside these transaction boundaries. Grails also permits both automatic schema updates and migration-based rollback without enforcing a single source of truth.

In multi-datasource configurations, migrations and rollbacks must be coordinated across every datasource to avoid partial states. The unresolved issue is identifying the reliable rollback boundary when these mechanisms intersect.

Does the database-migration plugin rollback task treat multiple datasources as one atomic unit, or does it reverse changesets independently per datasource?
What is the expected behavior when hbm2ddl.auto has already modified a schema outside the changelog before a rollback is attempted?
How can teams coordinate rollback across datasources to prevent partial states when the database does not support transactional DDL?

Wasi · Answer

Direct answer
No. The Grails database-migration plugin does not treat multiple datasources as one atomic rollback unit. Liquibase tracks changes in a separate DATABASECHANGELOG table for each datasource, and rollback executes independently per datasource. If the second datasource fails, the first is not automatically undone. The only reliable boundary is a single changeset on a single datasource, and only when that engine supports transactional DDL.

What happens when hbm2ddl has already altered the schema
If hbm2ddl.auto or the Grails dbCreate setting has modified the schema outside the changelog, rollback cannot see or reverse that drift. The plugin compares changelog history, not the live schema, so it may fail on missing objects or appear to succeed while leaving the database inconsistent with the recorded changesets.

Coordinating rollback across datasources

Make Liquibase the only schema writer. Disable automatic DDL by setting dbCreate: none and ensuring hbm2ddl.auto is not set to update or create in any environment where migrations run.
Require explicit rollback blocks. Every changeset should define rollback logic; implicit rollback is unreliable for complex DDL.
Run sequentially in dependency order. Roll back datasources one at a time, never concurrently, and respect Liquibase's per-datasource locking.
Back up and verify after each datasource. Compare the schema against the expected pre-change state before proceeding to the next datasource. Stop on first failure and repair or restore before continuing.
Rehearse on a clone. Test the full rollback sequence on a restored copy of production data.

Version-sensitive verification
Assuming a recent Grails line with the database-migration plugin, use the plugin's status task (for example, dbm-status) to confirm pending changesets for each datasource, and preview generated SQL with the rollback SQL task (for example, dbm-rollback-sql) before executing anything. Exact task names and flags are version-sensitive, so confirm them against your plugin version.

The one diagnostic that changes the recommendation
Provide the database engine and version for each datasource, specifically whether it supports transactional DDL. If an engine supports transactional DDL, per-datasource rollback can be atomic for that datasource alone. If not, even single-datasource rollback is only as safe as the last verified backup, and cross-datasource coordination must rely entirely on the sequential checkpoints above.

Can Grails database-migration rollback safely reverse schema changes across multiple datasources when DDL is non-transactional?

1 answer

Direct answer

What happens when hbm2ddl has already altered the schema

Coordinating rollback across datasources

Version-sensitive verification

The one diagnostic that changes the recommendation

Your perspective belongs here.

0 question comments