What is Preconditions?
Definition
A Precondition might check whether a table already exists, whether a specific database platform is in use, or whether a previous ChangeSet has already run. If the condition isn't met, the associated ChangeSet is skipped, marked as an error, or handled however the Precondition is configured to respond, rather than executing against a database it wasn't written for. This matters most when a single ChangeLog has to run safely across databases that might be in slightly different states: a fresh database, one that's partially updated, or one where a change was already applied manually. Preconditions let the ChangeLog account for that variation explicitly instead of assuming every target database looks the same.
Why Preconditions matter
A change written assuming a table already exists will fail, sometimes badly, if it runs against a database where that table isn't there yet. Preconditions give a ChangeSet a way to check its own assumptions before running, rather than discovering they were wrong midway through execution. That distinction matters most in exactly the situations where deployments already carry the most risk: a database that's been through an unusual history, an environment that isn't perfectly in sync with the others. They're also useful defensively, catching a ChangeSet that's accidentally about to run against the wrong database entirely.
How Preconditions work
A Precondition is attached to either an entire ChangeLog or a specific ChangeSet and defines a condition that has to hold true, such as a table existing, a row count matching an expectation, or a specific database product being in use. Before the associated change runs, the Precondition is evaluated; if it fails, the configured behavior takes over, which might mean skipping the ChangeSet, halting the ChangeLog, or logging a warning and continuing, depending on how strictly the team wants failures handled. Multiple Preconditions can be combined with logical operators, letting a single ChangeSet check several assumptions at once before it's allowed to proceed.
How Liquibase helps
Liquibase evaluates Preconditions automatically as part of running a ChangeLog, so a check that would otherwise require a person to manually verify database state before every deployment happens as a built-in step instead. Combined with Policy Checks, Preconditions let a team enforce both organizational standards, through Policy Checks, and change-specific safety assumptions, through Preconditions, using the same declarative ChangeLog, without maintaining a separate manual verification process alongside it. Because Preconditions are declarative rather than imperative, they can be reviewed in a pull request alongside the change they protect, making the safety assumption itself part of the reviewable change rather than tribal knowledge held only by whoever wrote the original ChangeSet.
