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

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?