// the take
A Django management command that statically analyses your migration files and flags backward-incompatible operations (dropping columns/tables, adding NOT NULL without a default, renaming things) before they hit CI. For teams doing rolling deploys where old code and new migrations coexist for a few minutes, this is the kind of thing that saves you from a 2am rollback.
It plugs into both ends of the workflow - `lintmigrations` for CI and a `makemigrations --lint` hook that can delete the just-generated migration on the spot, so bad migrations never get committed in the first place. Backend-specific analysers for Postgres, MySQL and SQLite mean it understands that MySQL's lack of transactional DDL and Postgres's lock behavior are different problems, not one generic ruleset. There's a caching layer (`cache.py`) keyed on migration content so re-running the linter in CI doesn't re-analyse migrations that haven't changed, which matters once a project has a few hundred of them.
It's pure static analysis of the operation list, not a dry-run against a shadow schema - a `RunSQL` or `RunPython` operation with a problematic query inside it won't be caught, and the dedicated `test_data_migrations.py` tests suggest data migrations are the shakiest part of the tool. It tells you a migration is unsafe but doesn't help you write the safe multi-step version (add nullable column → backfill → add NOT NULL), so you still have to know the pattern yourself. It's effectively a single-maintainer project (David Wobrock) for something teams end up wiring into every CI pipeline - worth checking issue response times before you depend on it for a blocking check.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →