DBLift 5.0 and 5.1: a modular install, and why

DBLift 5.0 was released on 24 October 2026. DBLift 5.1 was released on 27 October 2026 (GitHub and PyPI). The command names are the same. What changed is how DBLift is packaged. This post covers that change, the install lines to use now, and the reason behind it. The full lists are in the 5.0.0 and 5.1.0 release notes.

What DBLift 5.0 changed in packaging

Before 5.0, pip install dblift installed everything: the migration engine, the terminal display libraries, and the SQL analysis engine. In DBLift 5.0 the base wheel is a light core:

• pip install dblift installs PyYAML and SQLAlchemy, and nothing else.
• The rest is in extras.

The core still runs migrations. On a bare install, migrate --analysis-mode execution and validate work. The Python API defaults to execution mode and stays silent unless you set a logging option.

What DBLift 5.1 simplifies

In 5.0, the command line needed two extras: dblift[cli,analysis,<driver>]. The CLI uses full SQL analysis by default, but installing dblift[cli] previously omitted SQLGlot, so DBLift 5.1 makes cli include analysis. The install line is now:

pip install "dblift[cli,<driver>]"

PostgreSQL:

pip install "dblift[cli,postgresql]"

SQLite has no driver extra:

pip install "dblift[cli]"

Quote the brackets in zsh. Square brackets are glob characters.

The 5.0 line, dblift[cli,analysis,<driver>], still works on 5.1. The extra analysis is simply redundant now. The django, flask, fastapi, mcp and all extras behave as before: they already bring in the console and analysis. A driver extra on its own still installs only the driver, so add cli if you want the dblift command.

For library users, nothing changes. pip install dblift stays light, and analysis stays available on its own. Install dblift[analysis] and pass analysis_mode="full" when your application should get the same SQL analysis verdicts as the CLI. Add log_level="INFO" to see the logs.

from sqlalchemy import create_engine

from dblift.api import DBLiftClient

engine = create_engine("sqlite:///shop.db")

with DBLiftClient.from_sqlalchemy(
    engine=engine,
    migrations_dir="migrations",
    analysis_mode="full",
    log_level="INFO",
) as client:
    client.validate()
    client.migrate()

Why DBLift split the install

DBLift is a command-line tool, and it is also a Python library. An application that runs its migrations at startup may want a structured result, its own logging, and SQL that was already checked in CI. It does not need the display libraries or the analysis engine forced on it. Splitting them out reduces the mandatory dependencies and the compatibility constraints for the projects that embed DBLift.

Execution and analysis are different responsibilities. Correctly splitting a script so it can run is not the same job as understanding precisely what it does. Execution mode keeps the migration mechanics (history, locking, ordering) and drops the enrichment and warnings that come from analysis, so the two modes do not provide the same information. A library user can choose which one they need. See analysis mode for embedded execution.

5.1 keeps that split where it matters, in the core, and removes it where it only added typing, on the command line.

FAQ

How do I install DBLift 5.1?

pip install "dblift[cli,<driver>]" for a server engine, and pip install "dblift[cli]" for SQLite. The installation page has the extras table.

Do I need to change a DBLift 5.0 install line?

No. dblift[cli,analysis,<driver>] still works. You can drop analysis when you next touch it.

What does a bare pip install dblift give me?

PyYAML and SQLAlchemy, for embedding DBLift in an application. Migrations run in execution mode. Add dblift[analysis] for full SQL analysis.

Read next

• Install
• Python API
• Releases