Data management

Schema migrations change structure. Data sets change rows — the one-off UPDATE, INSERT and DELETE that support and operations apply against live data because the application does not expose them.

The path is the same idea as a migration, pointed at DML: a file is planned, reviewed, applied under row-count assertions, and written to an audit ledger. With Enterprise, apply also captures before/after row images so the correction can be reversed. Plans and command output never contain row data, so nothing sensitive lands in git, CI logs, or review tooling.

[!WARNING] Not a backup or disaster-recovery mechanism

Undo is a targeted, point-in-time reversal of a correction DBLift itself made. The before-images live inside the same database as your data, so they share its blast radius: they cannot recover from DROP TABLE, disk loss, ransomware, infrastructure failure, or any change DBLift did not make. Keep your normal backups and PITR — undo complements them, it does not replace them.

Versus schema migrations

A data correction is not a substitute for a migration. If the change is structural, use a V file. If it is a row fix that should be reviewed, asserted, and auditable, use a data set.

What each licence unlocks

A Pro apply still writes the ledger. Without Enterprise there is simply nothing to reverse. Running data undo without an Enterprise licence fails with a clear message, never a traceback.

See dblift data for the CLI split.

The loop

dblift data plan --dataset billing --output plan.json
# review plan.json in the PR — no row data in it
dblift data apply plan.json
dblift data status --dataset billing
# Enterprise:
dblift data undo D20260618143022 --dataset billing

plan is static. apply re-runs the selection, checks each expect, and appends a hash-chained ledger row. status lists each correction and verifies the chain. undo restores the before-image captured when that correction was applied.

Prefer a new compensating correction (fix-forward) over undo for anything beyond a recent, isolated mistake. Undo is best-effort and point-in-time: it is sensitive to later drift, capture size, and whether identifying keys were configured.

Author a correction

Files live under one of your data_sets.<name>.directories. The D token is the correction id — the handle data undo takes — and corrections run in ascending timestamp order.

D20260618143022__promote_account_tier.sql

-- dblift:formatted
-- dblift: expect=1
UPDATE "app"."accounts" SET tier = 'gold' WHERE id = 7;
-- dblift: expect=>=1 onfail=warn
UPDATE "app"."audit_log" SET note = 'tier change' WHERE account_id = 7;

-- dblift:formatted anywhere in the file turns on directive parsing. Without it the file still runs, but every expect is ignored and statements use the defaults (expect >=1).

See data_sets for the set, its identifying keys, and the policy that can refuse a plan at apply.

Related

• data — CLI reference, including which subcommand is Pro or Enterprise
• data_sets — configuration
• Undo model — reversing schema migrations, not rows
• Editions & tiers