Partial migration causing django_migrations table out of sync during zero-downtime deploy

When a Django application is upgraded, the migrate command applies each migration sequentially and records the migration name in the django_migrations table. The goal is to keep the application online while the schema evolves, which requires that the table entry and the actual database schema remain aligned after each step.

The uncertainty lies in how to handle migrations on backends that do not support transactional DDL. Enabling Migration.atomic=False can bypass automatic transaction wrapping, but it does not provide online schema change mechanisms, and RunPython operations still execute within the same transaction context, potentially leaving partial changes if a DDL statement commits early. The precise approach to guarantee consistency across PostgreSQL, MySQL, and SQLite while avoiding downtime has not been resolved.

How can a small Django app guarantee that django_migrations stays in sync with the live schema during incremental, zero‑downtime migrations? Is there a reliable pattern for using Migration.atomic=False together with RunPython to offset non‑transactional DDL on MySQL or SQLite? What deployment coordination strategy prevents table locks while ensuring the django_migrations entry reflects the final schema state?