Skip to main content

zero-downtime-migrations (zdm)

A PostgreSQL migration safety linter for Django and Alembic.

Why

Deploying database migrations without downtime requires careful attention to how PostgreSQL acquires locks. Operations like adding an index, altering a column to NOT NULL, or adding a foreign key can lock tables for extended periods on large datasets, blocking reads and writes and causing outages. zdm statically analyzes Django migrations and supported Alembic revisions to catch these unsafe patterns before they reach production, helping teams ship schema changes safely during normal deployments.

What

A standalone Rust CLI tool that statically analyzes Django and Alembic migration files to catch unsafe patterns that cause table locks, outages, and data loss on large PostgreSQL databases. Distributed like ruff/uv — a single fast binary, installable via pip, uvx, or standalone download.

Supports Django 3.2+ — zdm parses migration files directly without importing Django, so it works with any Django version and doesn't require Django to be installed.

Alembic support

zdm also discovers Alembic revision scripts directly under alembic/versions/*.py. It statically supports direct op.* calls in upgrade():

  • create_table, create_index, drop_index
  • create_foreign_key and create_check_constraint (including postgresql_not_valid=True), plus create_exclude_constraint
  • alter_column(nullable=False) and alter_column(new_column_name=...)
  • drop_column and execute("<static SQL>")

Use postgresql_concurrently=True only inside the canonical boundary:

with op.get_context().autocommit_block():
    op.create_index("jobs_state_idx", "jobs", ["state"], postgresql_concurrently=True)

The Alembic path is intentionally static: zdm does not import or execute revision scripts, connect to a database, inspect SQLAlchemy models, resolve aliases/custom operations, or evaluate dynamic SQL. op.execute is inspected only when its first positional argument or sqltext keyword is a string literal; use explicit SQL when you want it checked.

Installation

Breaking change: the zero-downtime-migrations command alias has been removed. Use zdm. (alias zero-downtime-migrations=zdm in your shell is a one-line workaround if you depended on the old name.)

# Install via pip (PyPI package is django-zdm; binary is `zdm`)
pip install django-zdm

# Or use uvx to run without installing
uvx --from django-zdm zdm .

# Or install with pipx
pipx install django-zdm

Usage

# Lint a single migration
zdm app/migrations/0042_add_index.py
zdm alembic/versions/20260809_add_jobs.py

# Lint all migrations in a directory
zdm app/migrations/

# Lint all migrations in the project
zdm .

# Diff mode: lint changed migrations in a PR
zdm --diff origin/main

# Staged diff mode: lint changes being committed by pre-commit
zdm --diff-staged origin/main

# Output formats
zdm --output-format json .
zdm --output-format compact .

# Select/ignore specific rules
zdm --select R001,R003 .
zdm --ignore R008 .

# Show explanation for a rule
zdm rule R001

# List every rule the binary recognises
zdm --list-rules

# Treat warnings as errors
zdm --warnings-as-errors .

--diff compares the merge base to HEAD and reads file contents from the HEAD tree, giving deterministic PR/CI results even when the worktree is dirty. --diff-staged compares the same merge base to the index and reads the staged blobs.

Exit Codes

  • 0 — no issues found
  • 1 — lint violations found (errors). Warnings alone do NOT cause exit code 1 unless --warnings-as-errors is set.
  • 2 — tool error (bad arguments, config parse failure, invalid file path)

JSON Output Schema

zdm --output-format json writes a single JSON object to stdout:

{
  "diagnostics": [
    {
      "rule_id":   "R001",
      "rule_name": "non-concurrent-add-index",
      "severity":  "error",
      "message":   "Use AddIndexConcurrently instead of AddIndex …",
      "path":      "app/migrations/0001_bad.py",
      "line":      8,
      "column":    9,
      "help":      "Replace migrations.AddIndex with …"
    }
  ],
  "summary": { "total": 1, "errors": 1, "warnings": 0 }
}

severity is "error" or "warning". help is null when the rule has no help text. The schema is pinned by the integration test suite — every field above is guaranteed on every diagnostic.

Rules

Rule Name Severity Description
R001 non-concurrent-add-index Error Use AddIndexConcurrently instead of AddIndex
R002 unique-constraint-without-index Error Unique constraints should have a concurrent index
R003 runsql-create-index Error Use AddIndexConcurrently instead of raw SQL CREATE INDEX
R004 missing-atomic-false Error Non-atomic migrations require atomic = False
R005 remove-field-without-separate Error Use SeparateDatabaseAndState to remove fields safely
R006 add-field-foreign-key Error Adding FK creates index and validates constraint (merged R007)
R008 disallowed-file-changes Error Don't change app code alongside migrations
R009 separate-db-state-same-pr Error Don't deploy both steps of SeparateDatabaseAndState together
R010 add-field-not-null Error Adding NOT NULL field without default rewrites table
R011 rename-field Error Renaming fields can break running code
R012 irreversible-run-python Warning RunPython should have a reverse function
R013 irreversible-run-sql Warning RunSQL should have a reverse SQL
R014 model-imports Error Don't import models in RunPython
R015 alter-field-not-null Warning AlterField whose result is NOT NULL may scan every row
R016 non-concurrent-remove-index Error Use RemoveIndexConcurrently instead of RemoveIndex
R017 non-concurrent-add-constraint Error CHECK constraint validates all rows; EXCLUDE constraint builds an index non-concurrently

For Alembic revisions, zdm evaluates R001, R003-R005, R011, R015-R017 against direct op.* calls in upgrade(). In diff modes, changeset rule R008 also applies. The Django API references in this table apply only to Django; Alembic diagnostics name their equivalent operations.

CreateModel Exemption

Several rules (R001, R002, R006, R010, R016, R017) automatically exempt operations that target models created in the same migration. This is because operations on newly created (empty) tables don't cause the locking issues these rules detect. The exemption is order-aware—a CreateModel that runs after the flagged op cannot retroactively exempt it—and follows RenameModel when the fresh table is renamed before a later operation.

Note: R007 (fk-without-concurrent-index) was merged into R006 and retired. R006 now takes the conservative stance that a prebuilt concurrent index does not make a one-step AddField(ForeignKey) safe on an existing table. Split the rollout instead of relying on an index exemption.

For example, this migration will NOT trigger R001:

class Migration(migrations.Migration):
    operations = [
        migrations.CreateModel(
            name='Order',
            fields=[('id', models.AutoField(primary_key=True))],
        ),
        migrations.AddIndex(  # Exempt: 'order' was just created above
            model_name='order',
            index=models.Index(fields=['created_at'], name='order_idx'),
        ),
    ]

R015 Limitation

R015 (alter-field-not-null) cannot tell, from a single AlterField operation, whether the column was previously nullable. It flags any AlterField whose resulting field is NOT NULL, which catches a genuine nullable→NOT NULL transition (the dangerous case) alongside benign re-stipulations of an already-NOT-NULL column. Because static analysis has no schema history, the rule emits Warning rather than Error — surfaced for review without breaking CI. Add # zdm: ignore R015 on operations you have verified are safe.

Inline Suppression

You can silence specific rules on a per-operation basis with a comment:

operations = [
    # zdm: ignore R001
    migrations.AddIndex(
        model_name='order',
        index=models.Index(fields=['created_at'], name='order_idx'),
    ),
    migrations.AlterField(  # zdm: ignore R015, R010
        model_name='product',
        name='sku',
        field=models.CharField(max_length=50),
    ),
]

The comment can sit on the line just above the operation or on the same line as any line in the operation's range. Multiple rule IDs may be listed, separated by commas.

Configuration

Configure via pyproject.toml or zero-downtime-migrations.toml:

[tool.zdm]
select = ["R001", "R002"]
ignore = ["R008"]
warnings-as-errors = false
allowed-file-patterns = ["*.txt", "*.md", "models.py"]
exclude = ["**/test_migrations/**"]

Configuration Precedence

Settings are applied in this order (highest to lowest priority):

  1. CLI flags (--select, --ignore, --warnings-as-errors)
  2. zero-downtime-migrations.toml found in the current directory or a trusted repo ancestor
  3. pyproject.toml [tool.zdm] section in the same directory
  4. Default values

The config search starts in the current working directory. On Unix, if zdm is running inside a trusted git repository, it walks upward within that repository and stops at the first directory that contains zero-downtime-migrations.toml or a pyproject.toml with [tool.zdm]. The nearest .git is always the boundary; an untrusted boundary never falls through to an outer repository. A pyproject for another tool is ignored, so running zdm from repo/apps/myapp/migrations/ still picks up repo/zero-downtime-migrations.toml. Without a trusted .git ancestor—and on Windows, where zdm cannot yet validate repository ACL ownership—only the current directory is checked. Config inputs must be regular UTF-8 files no larger than 1 MiB.

CLI flags always override config file settings. If both zero-downtime-migrations.toml and pyproject.toml exist in the same directory, the standalone file takes precedence; multi-level merging is not performed.

Pre-commit Integration

Install zdm in the environment where pre-commit runs, then call that installed binary from your .pre-commit-config.yaml:

repos:
  - repo: local
    hooks:
      - id: zdm
        name: zdm
        entry: zdm
        language: system
        types: [python]
        files: (^|.*/)(migrations|alembic/versions)/.*\.py$
        exclude: __init__\.py$

Or use diff mode to only check changed migrations:

repos:
  - repo: local
    hooks:
      - id: zdm-diff
        name: zdm diff
        entry: zdm --diff-staged origin/main
        language: system
        pass_filenames: false
        always_run: true

The zdm-diff hook uses --diff-staged so it checks the staged index that pre-commit is validating, rather than the previous HEAD commit.

The repository also publishes source-based pre-commit hooks for users who prefer repo: https://github.com/Photoroom/zero-downtime-migrations with rev: <latest release tag>. Those hooks install the package from source, so Rust must be available in the pre-commit environment.

GitHub Actions

- uses: actions/checkout@v4
  with:
    # --diff needs the base ref and enough history to compute a merge base.
    fetch-depth: 0

- name: Install zdm
  run: pip install django-zdm

- name: Lint migrations
  run: zdm --diff origin/main

Rust library API

The Rust crate exposes a small programmatic API, but it remains experimental while the project is in the 0.x series. Prefer Migration::from_path or Migration::from_source, Config, and the built-in rule registries. Low-level parser, extractor, diagnostic-construction, discovery, and git helpers may change between minor 0.x releases.

Comparison with Other Tools

zdm django-migration-linter Django's makemigrations --check
Requires Django installed No Yes Yes
Requires project setup No Yes (settings.py) Yes (full environment)
Checks for missing migrations No No Yes
Checks for unsafe operations Yes (16 active rules; zdm --list-rules) Yes (~8 rules) No
Configurable via pyproject.toml Yes (walks up within trusted repos) Yes N/A
Can run without database Yes Yes No
Language Rust Python Python

When to use what:

  • Use makemigrations --check to ensure all model changes have migrations
  • Use zdm or django-migration-linter to catch unsafe migration patterns
  • zdm is useful when you want to run checks in CI without setting up Django, or when you need the additional rules (NOT NULL alterations, RenameField, irreversible migrations, RemoveIndex)

License

MIT

Release files for django-zdm 0.5.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for django-zdm 0.5.0
File Size Uploaded
django_zdm-0.5.0.tar.gz 119.4 kB Details

Built distributions (wheels)

Table of built distributions (wheels) for django-zdm 0.5.0
File
django_zdm-0.5.0-py3-none-win_arm64.whl Python 3 none Windows ARM64 Details
django_zdm-0.5.0-py3-none-win_amd64.whl Python 3 none Windows x86-64 Details
django_zdm-0.5.0-py3-none-manylinux_2_28_x86_64.whl Python 3 none Linux glibc 2.28+ x86-64 Details
django_zdm-0.5.0-py3-none-manylinux_2_28_aarch64.whl Python 3 none Linux glibc 2.28+ ARM64 Details
django_zdm-0.5.0-py3-none-macosx_11_0_arm64.whl Python 3 none macOS 11.0+ ARM64 Details
django_zdm-0.5.0-py3-none-macosx_10_12_x86_64.whl Python 3 none macOS 10.12+ x86-64 Details

Total release size: 7.1 MB

Release files / django_zdm-0.5.0.tar.gz

Download URL django_zdm-0.5.0.tar.gz
Size 119.4 kB
Tags Source
SHA-256 checksum
How to use checksums
106ae4b290fdf2265c97f78c53aaac1a62e05b0bfcf738bec0c2fa9dd3e16d88
BLAKE2b-256 checksum
How to use checksums
cd01f6e2f6433cabcd237f1c6664e81d30c137ec84baf8c7038c4261b27eb918
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 11, 2026.

Transparency log

Release files / django_zdm-0.5.0-py3-none-win_arm64.whl

Download URL django_zdm-0.5.0-py3-none-win_arm64.whl
Size 1.3 MB
Tags Python 3 Windows ARM64
SHA-256 checksum
How to use checksums
68cdcaae487b6eaa2642c608cdc75990968698086c87069a052afd515555dd27
BLAKE2b-256 checksum
How to use checksums
40865d60ec351d3cf3872e1221417ae7a89bbb85deef8b2997ba4a25d535c374
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 11, 2026.

Transparency log

Release files / django_zdm-0.5.0-py3-none-win_amd64.whl

Download URL django_zdm-0.5.0-py3-none-win_amd64.whl
Size 1.3 MB
Tags Python 3 Windows x86-64
SHA-256 checksum
How to use checksums
73aa5058c8c7765a3eb68c4cce3c342aaa287ffdd6e011b12acfba0e81b2106d
BLAKE2b-256 checksum
How to use checksums
591b3b322364262add3fb3ba555fc34dfe52fe2dc0ffce4eb9e00c7a17b1d4a4
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 11, 2026.

Transparency log

Release files / django_zdm-0.5.0-py3-none-manylinux_2_28_x86_64.whl

Download URL django_zdm-0.5.0-py3-none-manylinux_2_28_x86_64.whl
Size 1.2 MB
Tags Linux glibc 2.28+ x86-64 Python 3
SHA-256 checksum
How to use checksums
a746303490166ccd6f4d134c1182c3625541784f2519969749eb6e3af45b718f
BLAKE2b-256 checksum
How to use checksums
518f20b095d389ed50c3e820b239cdee703f9ac94998ac8cb20ae0bcb962bcd1
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 11, 2026.

Transparency log

Release files / django_zdm-0.5.0-py3-none-manylinux_2_28_aarch64.whl

Download URL django_zdm-0.5.0-py3-none-manylinux_2_28_aarch64.whl
Size 1.1 MB
Tags Linux glibc 2.28+ ARM64 Python 3
SHA-256 checksum
How to use checksums
6113de72b87ebe41c75e234ad8bba8fd2d186a8555542d7b459cbb7ce2a30c64
BLAKE2b-256 checksum
How to use checksums
0fd8ab6d757f8dca309f0d9e80fe8689bdce2a402861a1a6ece3cebc22cba018
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 11, 2026.

Transparency log

Release files / django_zdm-0.5.0-py3-none-macosx_11_0_arm64.whl

Download URL django_zdm-0.5.0-py3-none-macosx_11_0_arm64.whl
Size 1.0 MB
Tags Python 3 macOS 11.0+ ARM64
SHA-256 checksum
How to use checksums
f6d2205ced6d68f2abe05a0057780335876c365f49e0b5de4479160378c4fb85
BLAKE2b-256 checksum
How to use checksums
01d56bc7aa4747c62d14963c248fcd3eb98a8def632892b3bc63268f0673ade9
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 11, 2026.

Transparency log

Release files / django_zdm-0.5.0-py3-none-macosx_10_12_x86_64.whl

Download URL django_zdm-0.5.0-py3-none-macosx_10_12_x86_64.whl
Size 1.1 MB
Tags Python 3 macOS 10.12+ x86-64
SHA-256 checksum
How to use checksums
3c483785319aeb0fa153b7f9252bc881fc0ee23069d6cc42da7d230fde569d73
BLAKE2b-256 checksum
How to use checksums
07b67b250838e01fc95472be6208c35b39aed88ea990b2afdad91a953010c770
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 11, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.5.0 This release

7 release files

0.4.0

7 release files

0.3.2

5 release files

0.3.1

5 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page