zanith

Migrate

The CLI surface for schema change. Generate a plan from your declared schema, plan it against the live database, verify it on a shadow, apply it with per-step audit. Recovery for every destructive op.

The five-second tour

SHELL
# 1. Generate a plan from the diff between your schema and the live DB.
zanith migrate generate --name add_orders_index
 
# 2. Inspect the plan + risk score.
zanith migrate plan
 
# 3. Verify on a shadow database.
zanith migrate verify
 
# 4. Apply for real.
zanith migrate up
 
# 5. Audit later.
zanith migrate history --verbose

What's in this section

PageCovers
[Lifecycle](/docs/migrate/lifecycle)Every command, every flag, every artifact, with failure paths drawn in.
[Risk model](/docs/migrate/risk)Six named levels (0–5), twenty reason codes, three CI gates (--max-risk, --block, --fail-on).
[Shadow-DB verify](/docs/migrate/verify)Apply pending migrations on a parallel database, introspect, diff against the declared schema.
[Recovery](/docs/migrate/recover)Soft-drop, archive, restore, export, purge — the destructive-op safety net.
[Audit + history](/docs/migrate/audit)Four real Postgres tables track every migration. zanith migrate history reads them; snapshots let you replay.
[Expand-contract](/docs/migrate/expand-contract)expandContractRename, expandContractTypeChange — paired plans for safe schema changes under a live app.
[Preflight checks](/docs/migrate/preflight)Probe live data for the conditions that would fail the DDL — duplicates, orphans, NULLs.
[Programmatic API](/docs/migrate/programmatic-api)Embed the same surface the CLI uses — applyMigrations, listMigrationSteps, snapshots, artifacts.

What you do not do

You do not edit migration files by hand for the common path. The generator is deterministic — re-run it after a schema change and it produces the same plan. When you do hand-edit (a custom backfill, a manual data fix), the per-step audit table records exactly what happened so a later read makes the change auditable.