Database engine coverage: DuckDB, PostgreSQL clouds, and analytics platforms

How DBLift’s open core covers traditional RDBMS, DuckDB, PostgreSQL-compatible clouds, and related analytics targets — and which pip extras to install.

DBLift’s migration core is not limited to a short list of enterprise RDBMS logos. The open core targets traditional SQL databases, DuckDB, Cosmos DB and MongoDB, PostgreSQL-compatible clouds, and the analytics warehouses (depth varies by dialect — always check the docs).

This post is a practical map of what that means for install, configuration, and honest depth (migrate vs review features).

The coverage model

Think in three layers:

Primary engines — PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, DB2, SQLite, Azure Cosmos DB, MongoDB
PostgreSQL-compatible family — Neon, Supabase, Amazon Aurora PostgreSQL, Google AlloyDB, YugabyteDB, TimescaleDB, Citus, CockroachDB
Analytics — DuckDB, Amazon Redshift, Snowflake

Migrate workflows on the OSS core cover the engines listed in the docs matrix. Pro and Enterprise capabilities such as schema comparison, export-schema, offline plan, and preflight have dialect-dependent depth — always check the docs for the engine you care about.

Install with the right extra

Every extra installs the base package plus one driver. SQLite needs no extra: the driver ships with Python.

# Traditional RDBMS
pip install "dblift[postgresql]"
pip install "dblift[mysql]"
pip install "dblift[mariadb]"
pip install "dblift[sqlserver]"
pip install "dblift[oracle]"
pip install "dblift[db2]"

# Embedded and analytics
pip install "dblift[duckdb]"
pip install "dblift[redshift]"
pip install "dblift[snowflake]"

# Document stores (plugin + vendor SDK)
pip install "dblift[cosmosdb]"
pip install "dblift[mongodb]"

# PostgreSQL-compatible clouds: same psycopg driver, named extra
pip install "dblift[neon]"          # also: supabase, aurora-postgresql, alloydb,
                                    # yugabytedb, timescaledb, citus, cockroachdb

# Every driver, for a multi-engine CI image
pip install "dblift[all]"

The PostgreSQL-compatible extras all resolve to the same psycopg driver. Naming the one you use keeps the intent visible in pyproject.toml and lets DBLift pick the matching dialect quirks from the URL.

See the Download page for the full extras table.

Configuration sketch

YAML still looks the same; only the URL and driver change:

database:
  url: postgresql+psycopg://user:pass@ep-xxx.region.aws.neon.tech/app
  schema: public

migrations:
  directory: ./migrations

DuckDB example, no schema line needed:

database:
  url: duckdb:///./local.duckdb

migrations:
  directory: ./migrations

What teams usually do next

Run dblift validate and dblift migrate --dry-run --show-sql before apply
Keep undo scripts next to versioned migrations in the open core
Add Pro SQL review and schema comparison when PR risk grows
Add Enterprise plan/preflight when approvers need portable evidence

Honest limits

Marketing should not oversell dialect depth. Migrate is the OSS baseline across the matrix. Diff, export, plan, and preflight quality depend on generators and introspection for that engine. If a dialect is partial for a paid workflow, treat it as such in evaluation — and prefer the engines where your release path is fully exercised in CI.