What is a Tag?
Learn how tags work in Harness Database DevOps to mark database states, support rollback strategies, and align deployments with application releases.
A tag in Harness Database DevOps is a marker that identifies the state of your database at a specific point in time. Tags represent versions, releases, or checkpoints and are essential for enabling targeted rollbacks and traceable deployments.
Tags are recorded in the DATABASECHANGELOG table, a Liquibase-managed audit table that tracks every changeset applied to your database. You can create tags using either the tag command (manual, applied at deployment time) or the tagDatabase Change Type (changelog-driven, version-controlled alongside your schema).
Tag command
The tag command marks the current database state by writing a label to the most recent row in the DATABASECHANGELOG table. No changeset is created or executed; it is a metadata-only operation.
When you use the Harness Database DevOps apply step, tagging works in two phases:
The apply step checks whether the current database state is tagged before applying changes. If no tag exists at that point, it creates one automatically to guarantee a rollback target before any new changesets run.
After all changesets are applied, the apply step writes a post-deployment tag using the name you provided in the tag input field on the step configuration.

tagDatabase change type
The tagDatabase Change Type embeds a tag inside a changeset, making it part of your version-controlled changelog. When Liquibase executes this changeset, it inserts a new row into the DATABASECHANGELOG table containing the specified tag.
Behavior
Inserts a new row into
DATABASECHANGELOGwith the specified tag value.Can be used as a target for
update-to-tag(deploy only up to this tag) androllback(revert all changes after this tag).Cannot be combined with other Change Types in the same changeset due to Liquibase XSD schema restrictions. Attempting to combine them causes a Liquibase validation error before any SQL is executed.
When to use which
Use case
Use tag
Use tagDatabase
Manual tagging before rollback testing
✅
❌
Changelog-driven version tracking
❌
✅
CI/CD-based release tagging
❌
✅
Creating lightweight checkpoints
✅
❌
The tag command suits one-off, runtime checkpoints (for example, tagging before a hotfix). The tagDatabase Change Type suits repeatable, release-aligned tagging baked into your changelog.
Best practices
Tag after every application release to mark a known stable database state.
Use semantic versioning for tag names:
v1,v1.1,v2.Ensure tags reflect meaningful checkpoints so rollbacks target predictable states.
Sample tag flow
This structure allows rollbacks to specific versions based on real release points.
Tag
Includes changes
v1
changeset1, changeset2
v1.1
changeset3
v2
changeset4, changeset5
Frequently asked questions
Related concepts
Learn more about related concepts in Harness Database DevOps:
What is a Changeset?: Understand the unit of change that tags mark in the DATABASECHANGELOG table.
Using rollback tags with apply schema step: Step-by-step guide to configuring rollback targeting with tags.
Next steps
Tag Database Changeset: Configure the apply step to record a tag anchor even on no-op deployments.
Automatic and custom rollback: Set up rollback strategies in Harness Database DevOps pipelines.
Last updated
Was this helpful?