Labels in Liquibase are tags you can add to changesets to control which will be executed in any particular migration run.

Labels were added in Liquibase 3.3 to work like contexts, but “backwards” in who can specify logical expressions. In your changeset you can only specify a simple list of “labels” that apply to the changeset but at runtime you can write a complex expression to chose the labels you want to execute. This allows you to specify a changeset with labels=”qa, acme_inc” and then at runtime use expressions such as --labels="!acme_inc" or --labels="pro or (free and beta)".

Labels work best when you can simply enumerate/describe what a changeset is for, but the deployment time environment is complex to describe. An example of when labels would work well is when you can describe changesets as for a particular feature or version such as “1.0” and/or “shopping_cart” but the decision on which features and/or versions needs to run is complex and chosen at deployment time. Labels in this case would allow you to run with --labels="1.0 or (1.1 and shopping_cart)" to deploy the 1.0 changesets and only the 1.1. features related to the shopping cart to one database and --labels="1.0 or (1.1 and !shopping_cart)" to another database.