Getting started
What databases does DBLift support?
Twenty engines, with the same CLI on all of them. Relational: PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, IBM Db2, SQLite, DuckDB, Amazon Redshift, Snowflake, plus PostgreSQL-compatible services (Aurora, AlloyDB, Neon, Supabase, Citus, CockroachDB, TimescaleDB, YugabyteDB). Document stores: Azure Cosmos DB and MongoDB. Each engine except SQLite needs its pip extra — see the capability matrix.
How do I install DBLift?
pip install "dblift[cli,analysis,postgresql]" (quote the extra in zsh). SQLite needs no driver extra: pip install "dblift[cli,analysis]". There is no dblift[sqlite] extra. Combine extras when you need more than one driver, or use dblift[all] for every engine extra. Verify with dblift --version, then dblift db check-connection.
Can I adopt DBLift on an existing database?
Yes. dblift baseline --baseline-version X records the current schema so later versions run and earlier ones are skipped. Coming from Flyway, dblift import-flyway copies flyway_schema_history into DBLift's history table without touching your scripts.
Does DBLift support Python migrations?
Yes. Versioned .py files follow the same naming rules as SQL. Cosmos DB and MongoDB only accept Python migrations — a .sql file fails with DBLIFT-NOSQL-001 before anything runs.
Workflow and evidence
What is the difference between validate and validate-sql?
dblift validate is OSS. It needs the configured database and checks history, checksums, and ordering. In the open-source package (pip install "dblift[cli,analysis]", 4.11.0 or later), validate-sql needs no licence. It lints .sql files offline (no database) with 17 migration-safety rules and prints console or JSON. Commercial 4.6.0 is built on dblift 4.10.0 and still needs a Pro licence for validate-sql. Pro: a custom --rules-file, --rules security, --rules schema. Enterprise: named profiles, the best_practices, performance and naming packs, and individual rule IDs. It does not lint Python migrations.
What do plan and preflight produce?
Both are Enterprise and read a snapshot, not a live target. plan reports what a release would run. preflight does that and can rehearse the scripts in a throwaway container. Write HTML, JSON, text, or GitHub Actions output with --format and --output / --output-dir.
Does DBLift support rollback or undo?
Yes, when a paired U<version>__*.sql (or .py) file exists. dblift undo reverses the newest applied version that has a companion. dblift undo --target-version 1.0.0 rolls back everything newer than that version. Preview with --dry-run --show-sql.
What report formats are available?
migrate can write a text, JSON, or HTML command log (--log-format). OSS validate-sql prints console or JSON. HTML, SARIF, GitHub Actions, GitLab, and compact validate-sql output are Pro. plan and preflight write HTML, JSON, and text evidence bundles. OSS migrate/info/validate do not require a licence to produce their logs.
How Pro licensing works
What is a Pro seat?
A seat is required for each person who authors database-change scripts that Pro processes — including people who never run DBLift and only push to Git. Reviewers who do not author the change, and CI bots, do not need a seat. One organization key is not a site license for every committer.
Does CI need a license?
CI can use your organization's Pro key; pipelines do not need their own seats. That does not reduce human seats. If fifty people commit scripts that CI runs through Pro, you need fifty seats.
What is a production target?
A production database you run Pro commands against. Dev, test, staging, and CI do not count. Pro is licensed for up to 10 production targets per organization, no matter how many seats you buy. dblift license info will show seats and the cap.
What if we need more than 10 production databases or more than 30 seats?
Talk to us about Enterprise for custom seats, higher or unlimited production databases, and plan, preflight, and snapshot evidence.
CI/CD and editions
Can DBLift run in CI/CD pipelines?
Yes. On GitHub, start with uses: dblift/action@v1 to run migrate, validate, or info in the same job as application tests. An OSS gate is dblift validate and dblift info on every migration change. Add dblift validate-sql (open source since 4.11.0) for SQL lint. Enterprise pipelines add snapshot → plan → preflight, then migrate, and keep the HTML/JSON/SARIF files as job artifacts. Exit code 4 means a licence is required, not that a migration failed.
What is the difference between OSS, Pro, and Enterprise?
Two installs, three editions. pip install "dblift[cli,analysis]" is the open-source package: migrate, info, validate, validate-sql (4.11.0 or later; 17 migration-safety rules, console or JSON), undo, clean, baseline, repair, import-flyway, db, config. Commercial 4.6.0 is built on dblift 4.10.0 and still needs a Pro licence for validate-sql. The commercial build is a single distribution; the licence key chooses Pro or Enterprise. Pro adds diff, export-schema, a custom validate-sql --rules-file, --rules security, --rules schema, and data plan/apply/status. Enterprise adds named profiles, the best_practices, performance and naming packs, individual rule IDs, snapshot, plan, preflight, data undo, and managed secret providers. See Pricing and Licensing.
How do I activate a commercial licence?
On the commercial build: dblift license activate <your-license-key>. That writes ~/.dblift/license.key. In CI use DBLIFT_LICENSE_KEY or --license-key instead of a file. dblift license info shows the edition and expiry; dblift license check is the pipeline gate.
Ecosystem
Is DBLift compatible with Flyway?
Yes. Filenames follow the same V/U/R conventions. dblift import-flyway copies Flyway history (default table flyway_schema_history) into dblift_schema_history. Scripts are not rewritten.
Where is the open-source code?
github.com/dblift/dblift, Apache 2.0.
What is tag filtering?
Tags live in the filename: V1_0_0__add_users[auth,core].sql. Matching is case-sensitive. Filter with --tags auth or --exclude-tags billing on migrate, info, validate, and undo.