Choosing Between Hibernate SchemaUpdate and Liquibase Migrations for Rollback-Safe Production Deployments

Context

A Grails 6 application must support production schema changes that can be rolled back reliably within a defined maintenance window. The team currently uses dbCreate: "update" in development but recognizes it provides no rollback mechanism for failed deployments.

Trade-off

The grails-database-migration plugin (Liquibase) offers explicit rollback via dbmRollback, yet only changesets using reversible Liquibase refactorings (e.g., createTable, addColumn) roll back automatically. Destructive operations—column drops, type narrowing, constraint removals—require manually authored rollback SQL, which dbmGormDiff cannot generate. Running both dbCreate: "update" and the migration plugin concurrently is documented as unsafe because SchemaUpdate applies DDL outside Liquibase's DATABASECHANGELOG, causing drift that breaks rollback integrity.

Uncertainty

Test environments often use dbCreate: "create-drop" with H2, which does not exercise Liquibase rollback paths. Multi-tenancy schema-per-tenant features in GORM 8 add further ambiguity: the plugin's rollback behavior for tenant-specific schemas is undocumented and only experimentally verified per tenant, not globally.

Given these constraints, which approach provides a verifiable rollback path for a changeset containing a dropColumn operation in a multi-tenant schema? Should the team accept manual rollback authoring for every destructive change, or is there a documented pattern that preserves automated rollback without disabling dbCreate in CI?