Change Intelligence is Coming.

What is 
Migration Script
?

Definition

A migration script can be written two ways: as raw SQL, giving full control over exactly what runs but tying the script to one database platform's syntax, or as a declarative description of the change, like a Liquibase ChangeSet, which a tool translates into the correct SQL for whichever database it's actually running against. Declarative scripts trade some direct control for portability and for structure a tool can reason about; generating a rollback automatically, or checking a policy against the change, is much easier when the script describes what it's doing declaratively rather than as an opaque block of SQL.

Why the format of a migration script matters

A raw SQL script runs exactly as written, which is useful when a change needs something very specific to one database platform, but it also means the script has to be rewritten if the same change needs to run against a different platform, and there's no structure a tool can use to generate a rollback or check the script against a policy automatically. A declarative migration script trades some of that direct control for portability and structure. Teams that standardize on raw SQL scripts often end up building their own tooling to solve problems, tracking what's been applied, generating rollbacks, that a declarative format already solves.

What a migration script typically contains

At minimum, a migration script needs enough information to identify itself, so a system knows whether it's already been applied, and the actual instructions for the change. Liquibase's declarative format adds an ID, an author, and one or more change types describing the operation, plus optional rollback instructions and preconditions, all of which a raw SQL file doesn't have anywhere to express. Comments describing why a change was made, not just what it does, also tend to be more valuable months later than the technical content of the script itself.

How Liquibase helps

Liquibase supports both approaches: a migration can be written as a declarative ChangeSet, which Liquibase translates into the correct SQL for the target platform and can generate rollback logic for automatically, or as a raw SQL script for cases that need something specific a declarative format doesn't cover. Either way, the script becomes a ChangeSet inside a ChangeLog, tracked in the same tracking table and subject to the same policy checks as every other change, so a team isn't locked into one approach for every situation, and can choose whichever format a specific change actually calls for.