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[postgresql]" (quote the extra in zsh). SQLite is stdlib: pip install dblift. 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. dblift validate-sql is Pro. It lints .sql files offline (no database). A Pro licence runs a custom --rules-file or --rules security; named profiles and the other built-in packs need Enterprise. 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). validate-sql can emit HTML, SARIF, JSON, or GitHub Actions annotations. 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 (Pro) 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 is OSS: migrate, info, validate, undo, clean, baseline, repair, import-flyway, db, config. The commercial build is a single distribution; the licence key chooses Pro or Enterprise. Pro adds diff, export-schema, validate-sql (custom --rules-file or --rules security), and data plan/apply/status. Enterprise adds built-in validate-sql packs and profiles, 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.