Rolling back returns a database to a previous tracked state by executing your changesets’ rollback statements in reverse deployment order. If you are still deciding whether rolling back is the right mitigation, start with Decide whether to roll back or fix forward — this page is the doing.

Choose your target

• To a tag — rollback <tag> takes the database back to the state at a tagged point. This is the cleanest target, which is why tagging before each release is part of a good strategy.

• By count — rollback-count <n> undoes the last n changesets.

• To a date — rollback-to-date <date> undoes everything deployed after that moment.

• A specific changeset — targeted rollbacks (rollback-one-changeset) take back one change without unwinding everything after it. See What are targeted rollbacks?.

Preview before you run

Every rollback command has a -sql variant — rollback-sql, rollback-count-sql, rollback-to-date-sql — that prints the exact statements without touching the database. Read it before you run: this is where a missing or wrong rollback statement shows itself while it is still free. The output is also a reviewable artifact your pipeline can hold for approval.

Run and verify

Run the command through the same governed path as any change — policy checks apply to rollbacks too, and the operation reports to the dashboards. Then verify: the rolled-back changesets disappear from the DATABASECHANGELOG table, status lists them as pending again, and the operation record shows what was undone (see View database deployments).

A rollback is only as good as its statements: many modeled changes roll back automatically; SQL changelogs need explicit rollback blocks written at authoring time. If a changeset has no rollback statement, the command stops and tells you — see Create custom rollback statements.