Undo Model

DBLift does not guess how to reverse a migration. You write the reversal yourself as a matching U file, and undo runs those files in reverse order until it reaches the version you asked for.

Undo files pair with migrations

An undo file takes the same version as the migration it reverses, with a U prefix instead of V. The description is free text — describe the reversal, not the original change.

-- V1_0_1__add_email_column.sql  (forward)
ALTER TABLE users ADD COLUMN email VARCHAR(255);

-- U1_0_1__remove_email_column.sql  (reverse)
ALTER TABLE users DROP COLUMN email;

dblift info shows which applied migrations have a matching undo file and which do not — check it before you need one.

Rolling back

Preview the rollback SQL first:

dblift undo --dry-run --show-sql

Roll back everything applied after version 1.0.0:

dblift undo --target-version=1.0.0

--target-version names the version you want to end up at, not the one to remove. Use --target-version=0 to roll back everything.

Generating undo scripts

The Python API can draft undo files for you from the forward migration — one at a time with generate_undo_script(), or in bulk with generate_undo_scripts(). Treat the output as a first draft: review it, then commit it alongside the migration.

Undo restores structure, not data

Dropping a column reverses a column addition, but the values that column held are gone. For anything destructive, the undo file is a way back to the previous schema — not a substitute for a backup, and not a way to recover rows.

Better still, avoid needing it: on Enterprise, plan and preflight propose a zero-downtime rewrite for dangerous DDL, so the risky change can be split into safe phases before it ever reaches production.