How does Grails support database migrations?

Rather than relying purely on GORM's automatic schema generation (which is convenient for early development but risky for a production database with real data), Grails applications typically use the Database Migration plugin, built on Liquibase, to manage schema changes as explicit, version-controlled changesets.

1. Generate a changeset from the current domain model's differences against the database, either by hand-writing a changelog or using the plugin's diff/generation commands to produce one automatically from GORM mapping changes.
2. Review and commit the changelog as part of the codebase, alongside the domain class changes that motivated it, so schema evolution is tracked in version control the same way application code is.
3. Apply migrations at deployment time, either automatically on startup (common in development) or through an explicit migration step in a deployment pipeline (safer for production, where an unreviewed automatic schema change is riskier).

This gives teams a controlled, auditable path from one schema version to the next, tracked change by change, rather than relying on GORM's convenience auto-generation to silently reshape a production database — auto-generation is genuinely useful for rapid local development, but explicit, reviewed migrations are the standard practice for anything running against a real, persistent database.