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

Direct answer

For a production Grails 6 application that must be able to roll back a dropColumn change in a schema‑per‑tenant setup, the only verifiable path is to use the grails‑database‑migration (Liquibase) plugin exclusively, disable Hibernate’s dbCreate (set to none or validate), and author a manual <rollback> section that re‑adds the column. Automatic rollback cannot be achieved for destructive operations, and running SchemaUpdate alongside Liquibase breaks rollback integrity.

Confirmed facts

• Hibernate SchemaUpdate applies DDL directly and provides no rollback mechanism; a dropColumn cannot be undone by Hibernate alone.
• The Liquibase plugin rolls back a changeset only when the change uses a reversible refactoring; dropColumn is not reversible, so a manual <rollback> containing the corresponding addColumn SQL is required for dbmRollback to succeed.
• In GORM 8 schema‑per‑tenant multi‑tenancy, Liquibase runs against the datasource bound to the current tenant; rollback commands affect only that tenant’s schema, meaning the manual SQL must be tenant‑aware (or executed per tenant).
• Running dbCreate: "update" together with dbmUpdate is unsafe because SchemaUpdate executes DDL outside Liquibase’s DATABASECHANGELOG, causing drift that invalidates Liquibase‑based rollback.

Likely explanation

Because the only way to guarantee a deterministic inverse of a destructive column drop is to store the exact inverse SQL yourself, the migration framework must be the sole source of truth for schema changes. Disabling dbCreate prevents Hibernate from applying out‑of‑band DDL that would otherwise create drift and break the Liquibase changelog.

1. Set dbCreate: "none" (or validate if you want startup validation) in application.yml for all environments.
2. Create a Liquibase changeset that drops the column and includes a manual rollback:

<changeSet id="20261013-drop-col" author="dev">
    <dropColumn tableName="my_table" columnName="old_col"/>
    <rollback>
        <addColumn tableName="my_table">
            <column name="old_col" type="varchar(255)"/>
        </addColumn>
    </rollback>
</changeSet>

3. Run grails dbmUpdate to apply the change to each tenant datasource (or iterate over your tenant list).
4. Verify the column is absent.
5. To test rollback, run grails dbmRollback <count> (or target the specific changeSet) against each tenant and confirm the column is restored.
6. In CI, keep dbCreate: "validate" if you want Hibernate to check for drift without applying changes; otherwise leave it as none.

Missing diagnostic detail: Can the team safely set dbCreate: "validate" in their CI pipeline to let Hibernate detect schema drift without applying DDL? If yes, they can retain validation while still relying on Liquibase for all actual changes; if not, they must disable dbCreate entirely.