Preconditions make a changelog defensive: they verify assumptions about the database before a changeset runs, preventing unsafe or invalid migrations.
One-sentence definition (interview-ready)
Preconditions are checks evaluated before a changeset executes that ensure the database is in the expected state, otherwise Liquibase stops or alters execution safely.
What problem preconditions solve
Without preconditions:
- migrations assume the DB looks a certain way
- drift or partial history causes runtime failure
- destructive SQL may run blindly
With preconditions:
- Liquibase asks first, then changes
How preconditions improve safety
1️⃣ Prevent destructive or invalid operations
Example: don’t drop a column that doesn’t exist
<preConditions onFail="HALT">
<columnExists tableName="users" columnName="email"/>
</preConditions>
Without this:
ALTER TABLE users DROP COLUMN email;
-- fails or behaves unexpectedly
2️⃣ Protect against environment drift
Example: only run if table exists (maybe legacy DB)
<preConditions onFail="MARK_RAN">
<tableExists tableName="legacy_users"/>
</preConditions>
If table is missing:
- changeset is marked as executed
- no failure
- pipeline continues
3️⃣ Avoid partial production outages
Preconditions can stop deploy before risky DDL runs.
<preConditions onFail="HALT">
<dbms type="postgresql"/>
</preConditions>4️⃣ Enable idempotent and repeatable behavior
Preconditions let you safely express:
- “run this only if needed”
- “skip if already applied”
Example:
<preConditions onFail="MARK_RAN">
<not>
<indexExists indexName="idx_users_email"/>
</not>
</preConditions>
onFail strategies (this matters in interviews)
| onFail | Meaning | When to use |
|---|---|---|
HALT | Stop migration | Critical schema safety |
MARK_RAN | Skip but record | Legacy / optional changes |
WARN | Log warning | Observability only |
CONTINUE | Ignore failure | Rare, risky |
🚨 MARK_RAN is powerful but dangerous — use sparingly.
What preconditions are NOT
❌ Not a replacement for proper versioning
❌ Not a way to hide required schema changes
❌ Not for business logic checks
Interview pitfalls ❌
- “We use preconditions to make migrations optional everywhere”
- “MARK_RAN is safe by default”
- “Preconditions replace migration ordering”
All red flags.
Interview-ready answer (2–3 sentences)
Preconditions improve changelog safety by validating database assumptions before executing a changeset, preventing destructive or invalid operations. They allow Liquibase to halt, skip, or warn based on controlled failure modes, which is especially useful for handling legacy schemas and environment drift safely.
Senior rule of thumb
Preconditions turn migrations from blind scripts into defensive operations.