What is Backward-Compatible Schema Change?
Definition
Adding a new, optional column is typically backward-compatible, since existing code that doesn't know about it keeps working unaffected. Renaming a column, changing its type in an incompatible way, or making a previously optional field required are typically not, since they change assumptions that existing code depends on. The distinction matters most during any deployment where old and new application code might run simultaneously against the same database, which is close to guaranteed in any rolling or gradual deployment strategy. Evaluating whether a specific change is backward-compatible is usually the first question worth asking before deciding how, or whether, it needs to be broken into smaller steps.
Why backward compatibility matters
Most production deployments aren't instantaneous: a rolling deployment might run old and new application code side by side for minutes or longer, and even a fast deployment leaves a brief window where in-flight requests are still using the old code. A schema change that isn't backward-compatible turns that normal, brief window into an active incident, since the old code breaks the moment the schema changes underneath it, often for every request rather than intermittently.
How to evaluate backward compatibility
The general test is whether code written against the old schema continues to function correctly against the new one. Purely additive changes, a new nullable column, a new table, usually pass this test. Changes that remove, rename, or restrict something existing code relies on usually don't, and typically need to be handled through a pattern like Expand-Contract that spreads the change across multiple backward-compatible steps instead of one incompatible one. It's worth checking both the read path and the write path separately, since a change can be safe for one and not the other.
How Liquibase helps
Liquibase's Change Types and Preconditions make it possible to verify assumptions about a database's state before a change runs, which is central to catching compatibility problems before deployment rather than after. Combined with Policy Checks, a rule can specifically flag potentially incompatible operations, like a column type change or a not-null constraint being added without a default, for extra review before they're allowed to deploy. When in doubt, defaulting to the more cautious, multi-step approach costs little extra effort compared to the risk of guessing wrong about compatibility and finding out during a live deployment instead of during review. Communicating a compatibility assessment clearly in a pull request description, not just relying on a reviewer to infer it, tends to speed up review meaningfully for anyone unfamiliar with the specific change being proposed.
