What is Change Set?
Definition
Breaking database changes into individual change sets, rather than one large script, makes each change independently trackable: a single change set can be reviewed, tested, rolled back, or skipped in a given environment without touching the others around it. Each one is recorded once it runs, in a dedicated tracking table, so re-running the same ChangeLog later only applies whatever change sets haven't been applied yet. A ChangeLog is effectively a sequence of change sets, similar to how a codebase is a sequence of commits. That granularity is what makes database changes reviewable in a pull request: a reviewer looking at one change set can see exactly what it does, rather than parsing a long script for the one line that matters.
Why change sets matter
A single large script that runs several changes at once is hard to review, hard to partially roll back, and hard to reason about after the fact. If it fails halfway through, there's often no clean way to know which parts succeeded. Breaking the same work into individual change sets solves both problems: each one either succeeds or fails on its own, gets tracked on its own, and can be rolled back on its own, so a failure in one doesn't leave the rest in an unknown state. This same granularity is what makes a ChangeLog readable months later: scanning a list of small, well-labeled change sets tells a new team member what happened to a database over time far more clearly than a handful of large, undifferentiated scripts would.
How change sets work
Each change set has an ID and an author, which together make it unique within a ChangeLog, plus one or more change types describing what it does, such as creating a table or adding a constraint. When a ChangeLog runs, Liquibase checks its tracking table for change sets that have already been applied and skips them, so the same ChangeLog can be run repeatedly across environments without reapplying anything twice. Preconditions can be attached to an individual change set to make its execution conditional on the state of the database, and Contexts or Labels can restrict a change set to specific environments. Because each change set is independently identified, two developers can add unrelated change sets to the same ChangeLog in parallel without either one blocking the other, the same way independent commits don't block each other in source control.
How Liquibase helps
Liquibase is built around the change set as its core unit of work: every command, from checking what's pending to rolling back a specific change, operates at the change set level. That granularity is what lets a team review a single change set in a pull request, deploy it independently, and trace exactly when it ran and by whom, using the same tracking table across every environment the ChangeLog touches.
