What is Schema Migration?
Definition
Schema migrations cover structural changes: creating or dropping tables, adding or modifying columns, adjusting constraints, and building indexes. They're distinct from data migrations, which move or transform the data itself, though the two often happen together; adding a column is a schema migration, and backfilling that column with derived values is a data migration layered on top. Because schema migrations change the shape a database expects data to be in, they carry particular risk for compatibility: an application built against an old schema can break the moment a migration changes a column it depends on, which is why sequencing and rollback matter more here than for most other kinds of change.
Why schema migrations need careful handling
A schema migration changes the contract between a database and everything that reads from or writes to it. An application expecting a column that a migration just renamed, or a column type that just changed, can fail immediately, sometimes for every request rather than gradually. This is part of why schema migrations are usually the specific target of version control and review discipline; structural changes have an outsized ability to break things compared to most other database operations. Coordinating the timing of a schema migration with the application release that depends on it is often the harder problem, more than writing the migration itself.
How schema migrations are managed
A schema migration is typically written as one or more ChangeSets describing the structural operation: create a table, add a column, drop a constraint. Because the operation is described declaratively rather than as raw SQL, the same migration can often be translated to the correct syntax for different database platforms automatically. Sequencing matters: a migration that adds a column has to run before a later migration that populates it, which is why migrations are applied in a defined, tracked order rather than independently. Many schema migrations can run without locking a table for the duration of the change, which matters for large tables in production where an extended lock would otherwise cause visible downtime.
How Liquibase helps
Liquibase's change types cover the common structural operations, create table, add column, add constraint, and more, as declarative descriptions rather than hand-written SQL, so the same schema migration can target more than sixty different database platforms without being rewritten for each one, which is particularly useful for organizations running the same application on more than one database engine. Rollback instructions can be generated automatically for many schema migrations, since structural operations like adding a column often have a clear, mechanical inverse.
