manage.py migrate в пятницу в 17:30 на проде с 3K RPS и таблицей 200М строк

• Сгенерированный SQL. Иногда не такой, который ты ожидал. Например, AlterField(max_length=64)для CharField(max_length=32) - это ALTER TABLE ... ALTER COLUMN TYPE varchar(64), и, да, на PostgreSQL это будет очень быстро. 

• Блокировки. PostgreSQL может блокировать таблицу так, что не пройдет даже SELECT. Очереди блокировок в PostgreSQL - это FIFO. То есть твоя миграция ждет долгую транзакцию пять минут, а за ней молча стоят ещё 200 запросов от пользователей. Никто не отвечает. Прод R.I.P.
  
• Python-код в RunPython. Он запускается прямо в транзакции миграции (если atomic = True, а это значение по умолчанию) и держит её открытой всё время выполнения. Developer.objects.all().update(...) на 50 миллионов строк - R.I.P.

• Кейс 1. Славик добавил поле is_archived =models.BooleanField(default=False) 
  в таблицу с 80 000 000 строк на PostgreSQL 13. Миграция отработала за 14 минут. Всё это время таблица была недоступна на запись. Прод лежал, весь автобус плакал. 
  
• Кейс 2. Владислав добавил models.Index(fields=['created_at']) в Meta модели Order.  CREATE INDEX без CONCURRENTLYвзял SHARE на таблице - все вставки заказов встали в очередь на десять минут. 
  
• Кейс 3. Васян написал data-миграцию для бэкфилла на 20M строк через Order.objects.filter(...).update(...). Миграция была атомарной по умолчанию. Один большой UPDATE сгенерил гигантский WAL, реплики залагали - R.I.P согласованность данных.

• ROW SHARE - SELECT FOR UPDATE/SHARE. Используется, когда запрос собирается блокировать строки; чуть строже обычного чтения.
  
• ROW EXCLUSIVE - INSERT, UPDATE, DELETE. Это стандартная DML-нагрузка: изменения данных разрешены параллельно, пока нет «тяжёлого» DDL. То есть обычные DML-операции не мешают друг другу, но серьёзные изменения структуры таблицы могут остановить или заблокировать их (REINDEX, ALTER TABLE ... TYPE, ALTER TABLE ... ADD COLUMN и т.д.).
  
• SHARE UPDATE EXCLUSIVE - VACUUM (без FULL), ANALYZE, CREATE INDEX CONCURRENTLY, ALTER TABLE VALIDATE CONSTRAINT, REINDEX CONCURRENTLY. Нужна для риалтайм-операций обслуживания: таблицу можно продолжать читать и менять.
  
• SHARE - CREATE INDEX (без CONCURRENTLY). Разрешает чтение, но блокирует INSERT/UPDATE/DELETE, потому что индекс строится в одном консистентном состоянии.
  
• SHARE ROW EXCLUSIVE - CREATE TRIGGER, некоторые ALTER TABLE. Более жёсткий DDL-режим: PostgreSQL защищает структуру таблицы от параллельных изменений.
  
• EXCLUSIVE - REFRESH MATERIALIZED VIEW CONCURRENTLY. Почти полная блокировка: читать можно, но любые изменения данных запрещены.
  
• ACCESS EXCLUSIVE - DROP TABLE, TRUNCATE, большинство ALTER TABLE, REINDEX. Самая сильная блокировка: останавливает вообще всё, включая обычный SELECT.

• ALTER TABLE ... ADD COLUMN (даже если мгновенно).
  
• ALTER TABLE ... DROP COLUMN.
  
• ALTER TABLE ... ALTER COLUMN TYPE (даже без REWRITE).
  
• ALTER TABLE ... ADD CONSTRAINT (без NOT VALID).
  
• CREATE INDEX (без CONCURRENTLY) - берёт SHARE, что не полный ACCESS EXCLUSIVE, но всё равно блокирует write.
  
• DROP INDEX (без CONCURRENTLY).
  
• ALTER TABLE ... RENAME.
  
• DROP TABLE, TRUNCATE, CLUSTER, VACUUM FULL.

T0: Аналитик запустил SELECT pg_dump таблицы users → берёт ACCESS SHARE на 5 минут.
T1: Запускается миграция ALTER TABLE users ADD COLUMN foo
    -> пытается взять ACCESS EXCLUSIVE -> ждёт.
T2: Пришёл API-запрос: SELECT * FROM users WHERE id = 42
    -> пытается взять ACCESS SHARE -> совместим с тем, что у аналитика,
       НО несовместим с тем, что ЖДЁТ миграция -> встаёт в очередь.
T3: Ещё 200 запросов -> все в очереди.
T4: Аналитик закончил.
T5: Миграция отработала за 5 мс.
T6: Очередь рассасывается.

# 0042_safe_alter.py
from django.db import migrations
class Migration(migrations.Migration):
    atomic = False
    dependencies = [...]
    operations = [
        migrations.RunSQL(
            sql="SET lock_timeout = '3s'; SET statement_timeout = '5min';",
            reverse_sql=migrations.RunSQL.noop,
        ),
        # ... основные операции
    ]

• средней длительности транзакций;
  
• профиля нагрузки;
  
• maintenance window;
  
• replication lag;
  
• количества параллельных записей.

migrations.RunSQL(
    sql=(
        "SET lock_timeout = '3s'; "
        "SET statement_timeout = '5min'; "
        "SET transaction_timeout = '10min';"  # PG 17+
    ),
    reverse_sql=migrations.RunSQL.noop,
),

python manage.py sqlmigrate developers 0042

• сколько операторов будет выполнено;
  
• есть ли ALTER TABLE ... ALTER COLUMN TYPE (потенциально REWRITE);
  
• есть ли CREATE INDEX без CONCURRENTLY;
  
• есть ли ADD CONSTRAINT без NOT VALID;
  
• завернет ли Django все в BEGIN ... COMMIT (если миграция атомарная).

BEGIN;
--
-- Alter field rating on developer
--
ALTER TABLE "developers_developer" ALTER COLUMN "rating" TYPE numeric(10, 2)
    USING "rating"::numeric(10, 2);
COMMIT;

BEGIN;
--
-- Add field nickname to developer
--
ALTER TABLE "developers_developer" ADD COLUMN "nickname" varchar(64) NULL;
COMMIT;

# PG 14+ (и даже 11+), БЕЗОПАСНО:
migrations.AddField(
    model_name='developer',
    name='is_archived',
    field=models.BooleanField(default=False),
),

# ОПАСНО на любом PG:
migrations.AddField(
    model_name='developer',
    name='external_id',
    field=models.UUIDField(default=uuid.uuid4),
),

• AddField(null=True) - без default.
  
• RunPython(backfill_uuid) чанками с atomic=False.
  
• AlterField(null=False) - через AddConstraintNotValid + ValidateConstraint (см. ниже).

class Migration(migrations.Migration):
    atomic = False
    dependencies = [...]
    operations = [
        # 1. Колонка nullable, мгновенно.
        migrations.AddField(
            model_name='order',
            name='customer',
            field=models.ForeignKey(
                'customers.Customer', null=True,
                on_delete=models.PROTECT, db_constraint=False,
            ),
        ),
        # 2. Добавляем FK как NOT VALID - мгновенно (берёт ACCESS EXCLUSIVE,
        #    но не сканирует таблицу).
        migrations.RunSQL(
            sql=(
                'ALTER TABLE "orders_order" '
                'ADD CONSTRAINT "orders_order_customer_fk" '
                'FOREIGN KEY ("customer_id") '
                'REFERENCES "customers_customer" ("id") NOT VALID;'
            ),
            reverse_sql=(
                'ALTER TABLE "orders_order" DROP CONSTRAINT "orders_order_customer_fk";'
            ),
        ),
        # 3. Валидируем существующие строки - SHARE UPDATE EXCLUSIVE,
        #    совместимо с DML, может идти долго, но прод работает.
        migrations.RunSQL(
            sql='ALTER TABLE "orders_order" VALIDATE CONSTRAINT "orders_order_customer_fk";',
            reverse_sql=migrations.RunSQL.noop,
        ),
    ]

# Было в модели:
class Meta:
    constraints = [
        models.UniqueConstraint(fields=['email'], name='user_email_uniq'),
    ]
# Стало:
class Meta:
    constraints = [
        models.UniqueConstraint(
            fields=['email'], name='user_email_uniq',
            violation_error_message='Email уже занят',
        ),
    ]

# Django 5.2 makemigrations:
operations = [
    migrations.AlterConstraint(
        model_name='user',
        name='user_email_uniq',
        constraint=models.UniqueConstraint(
            fields=['email'], name='user_email_uniq',
            violation_error_message='Email уже занят',
        ),
    ),
]

• Expand. Расширяем схему так, чтобы старый код продолжал работать (новые поля nullable, новые таблицы не используются, старые поля остаются).
  
• Migrate. Переводим логику и данные на новую схему. Обычно - несколько подэтапов с код-релизами между ними.
  
• Contract. Удаляем старое.

• На уровне PG: ALTER TABLE RENAME COLUMN - мгновенно, ACCESS EXCLUSIVE.
  
• На уровне приложения: между моментом, когда миграция применилась, и моментом, когда задеплоился новый код, старые инстансы приложения ходят в БД с запросом SELECT title FROM developers_developer и получают ошибку column "title" does not exist.

# developers/models.py
class Developer(models.Model):
    title = models.CharField(max_length=64)           # старое поле
    name = models.CharField(max_length=64, null=True) # новое поле
    @property
    def display_name(self):
        return self.name or self.title

class Migration(migrations.Migration):
    dependencies = [('developers', '0041_previous')]
    operations = [
        migrations.AddField(
            model_name='developer',
            name='name',
            field=models.CharField(max_length=64, null=True),
        ),
    ]

def copy_title_to_name(apps, schema_editor):
    Developer = apps.get_model('developers', 'Developer')
    db_alias = schema_editor.connection.alias
    from django.db.models import F
    BATCH_SIZE = 5000
    last_pk = 0
    while True:
        # Забираем очередной блок первичных ключей, строго pk > last_pk
        chunk = list(
            Developer.objects.using(db_alias)
            .filter(name__isnull=True, pk__gt=last_pk)
            .order_by('pk')
            .values_list('pk', flat=True)[:BATCH_SIZE]
        )
        if not chunk:
            break
        # Обновляем ровно этот блок
        (
            Developer.objects.using(db_alias)
            .filter(pk__in=chunk)
            .update(name=F('title'))
        )
        # Двигаем курсор
        last_pk = chunk[-1]
class Migration(migrations.Migration):
    atomic = False  # обязательно — батчи коммитятся независимо
    dependencies = [('developers', '0042_add_name_field')]
    operations = [
        migrations.RunPython(
            copy_title_to_name,
            reverse_code=migrations.RunPython.noop,
            elidable=True,  # при squash удалится — это разовая операция
        ),
    ]

def update_developer(developer: Developer, new_title: str) -> None:
    developer.title = new_title
    developer.name = new_title
    developer.save(update_fields=['title', 'name'])

class Developer(models.Model):
    title = models.CharField(max_length=64)
    name = models.CharField(max_length=64, null=True)
    @property
    def display_name(self):
        return self.name  # больше не fallback на title

class Developer(models.Model):
    name = models.CharField(max_length=64)  # теперь NOT NULL

operations = [
    # На этот момент 100% строк имеют name, проверяем CHECK NOT VALID + VALIDATE.
    AddConstraintNotValid(...),
    ValidateConstraint(...),
    migrations.AlterField(
        model_name='developer',
        name='name',
        field=models.CharField(max_length=64),  # null=False
    ),
    migrations.RemoveField(
        model_name='developer',
        name='title',
    ),
]

operations = [
    migrations.RenameField(
        model_name='developer',
        old_name='title',
        new_name='name',
    ),
]

from django.contrib.postgres.operations import (
    AddIndexConcurrently, RemoveIndexConcurrently,
)
from django.db import migrations, models
class Migration(migrations.Migration):
    atomic = False  # обязательно — CONCURRENTLY вне транзакции
    dependencies = [('developers', '0044_some_migration')]
    operations = [
        AddIndexConcurrently(
            model_name='developer',
            index=models.Index(
                fields=['rating'],
                name='developer_rating_idx',
            ),
        ),
    ]

-- Найти INVALID-индексы:
SELECT indexrelid::regclass AS index_name, indrelid::regclass AS table_name
FROM pg_index
WHERE indisvalid = false;
-- Удалить:
DROP INDEX CONCURRENTLY IF EXISTS developer_rating_idx;

from django.contrib.postgres.operations import AddConstraintNotValid, ValidateConstraint
from django.db import migrations, models
# Файл 0045_add_rating_constraint_not_valid.py
class Migration(migrations.Migration):
    dependencies = [('developers', '0044_previous')]
    operations = [
        AddConstraintNotValid(
            model_name='developer',
            constraint=models.CheckConstraint(
                condition=models.Q(rating__gte=0),  # ВАЖНО
                name='developer_rating_non_negative',
            ),
        ),
    ]
# ОТДЕЛЬНЫЙ файл 0046_validate_rating_constraint.py
class Migration(migrations.Migration):
    atomic = False  # VALIDATE может быть долгим
    dependencies = [('developers', '0045_add_rating_constraint_not_valid')]
    operations = [
        ValidateConstraint(
            model_name='developer',
            name='developer_rating_non_negative',
        ),
    ]

from django.db import migrations, models
class Migration(migrations.Migration):
    atomic = False
    dependencies = [('developers', '0046_previous')]
    operations = [
        migrations.SeparateDatabaseAndState(
            database_operations=[
                migrations.RunSQL(
                    sql=(
                        'CREATE UNIQUE INDEX CONCURRENTLY "developer_inn_uniq" '
                        'ON "developers_developer" ("inn");'
                    ),
                    reverse_sql=(
                        'DROP INDEX CONCURRENTLY IF EXISTS "developer_inn_uniq";'
                    ),
                ),
            ],
            state_operations=[
                migrations.AddConstraint(
                    model_name='developer',
                    constraint=models.UniqueConstraint(
                        fields=['inn'],
                        name='developer_inn_uniq',
                    ),
                ),
            ],
        ),
    ]

# Найти текущее имя индекса в БД:
# \d+ developers_developer в psql
# Или: SELECT indexname FROM pg_indexes WHERE tablename='developers_developer';
# Допустим, было developers_dev_a_b_idx.
# В Meta модели:
class Meta:
    indexes = [
        models.Index(fields=['a', 'b'], name='developers_dev_a_b_idx'),
    ]
# Миграция:
operations = [
    migrations.SeparateDatabaseAndState(
        database_operations=[],  # в БД ничего не делаем
        state_operations=[
            migrations.AlterIndexTogether(
                name='developer',
                index_together=set(),
            ),
            migrations.AddIndex(
                model_name='developer',
                index=models.Index(
                    fields=['a', 'b'],
                    name='developers_dev_a_b_idx',
                ),
            ),
        ],
    ),
]

class Developer(models.Model):
    # В коде — name, в БД — title
    name = models.CharField(max_length=64, db_column='title')

operations = [
    migrations.SeparateDatabaseAndState(
        database_operations=[],
        state_operations=[
            migrations.RenameField(
                model_name='developer',
                old_name='title',
                new_name='name',
            ),
            migrations.AlterField(
                model_name='developer',
                name='name',
                field=models.CharField(max_length=64, db_column='title'),
            ),
        ],
    ),
]

# В models.py — определяем through:
class Project(models.Model):
    developers = models.ManyToManyField(
        'developers.Developer',
        through='ProjectDeveloper',
    )
class ProjectDeveloper(models.Model):
    project = models.ForeignKey('Project', on_delete=models.CASCADE)
    developer = models.ForeignKey(
        'developers.Developer', on_delete=models.CASCADE,
    )
    class Meta:
        db_table = 'projects_project_developers'  # имя авто-таблицы M2M

• реальное состояние БД;
  
• migration state Django.

• Операции с CONCURRENTLY вообще запрещены внутри транзакции.
  
• Долгий бэкфилл данных в одной транзакции = ROW EXCLUSIVE на куче строк надолго + раздутый WAL.
  
• AddConstraintNotValid + VALIDATE хотим выполнить независимо, чтобы VALIDATE мог идти на проде без блокировок.

class Migration(migrations.Migration):
    atomic = False
    # ...

• SQL, выполненные до места ошибки, остаются применёнными в БД (Django выполняет операции отдельными transaction scopes, поэтому часть операций может успеть примениться до места ошибки)
  
• Запись в django_migrations не добавляется - Django не знает, что миграция применена частично.
  
• При повторном запуске Django начнёт миграцию с самого начала и упадёт на первой же операции с column already exists / index already exists.

migrations.RunSQL(
    sql='ALTER TABLE foo ADD COLUMN IF NOT EXISTS bar integer;',
    reverse_sql='ALTER TABLE foo DROP COLUMN IF EXISTS bar;',
),

python manage.py migrate developers 0045 --fake

• ROW EXCLUSIVE на куче строк надолго;
  
• гигабайт WAL - реплики залагают;
  
• если в atomic = True = одна гигантская транзакция, увеличение размера shared buffers, autovacuum не может работать;
  
• невозможно прервать без отката.

from django.db import migrations
def backfill_status(apps, schema_editor):
    Developer = apps.get_model('developers', 'Developer')
    db_alias = schema_editor.connection.alias
    BATCH_SIZE = 10_000
    qs = (
        Developer.objects.using(db_alias)
        .filter(status__isnull=True)
    )
    last_pk = 0
    while True:
        batch_qs = (
            qs.filter(pk__gt=last_pk)
               .order_by('pk')
        )
        # берём только границу диапазона
        batch = list(
            batch_qs.values_list('pk', flat=True)[:BATCH_SIZE]
        )
        if not batch:
            break
        start = batch[0]
        end = batch[-1]
        Developer.objects.using(db_alias).filter(
            pk__gte=start,
            pk__lte=end,
            status__isnull=True
        ).update(status='active')
        last_pk = end
class Migration(migrations.Migration):
    atomic = False
    dependencies = [('developers', '0050_add_status_field')]
    operations = [
        migrations.RunPython(
            backfill_status,
            reverse_code=migrations.RunPython.noop,
            elidable=True,
        ),
    ]

• apps.get_model(...), а не прямой импорт модели. Мы это обсуждали во второй статье. Импортированная модель - это "текущая" версия из models.py, в которой могут быть поля, ещё не существующие в БД. apps.get_model возвращает "историческую" модель - ровно такую, какой она была на момент этой миграции.
  
• using(db_alias). На случай multi-db schema_editor.connection.alias отдаст нужное имя БД. Если забыть - update()пойдёт в default-базу.
  
• reverse_code=migrations.RunPython.noop. Хорошо бы написать обратную функцию, но в случае бэкфилла это часто бессмысленно (исходного состояния "без статуса" больше не существует логически). noop говорит Django: "можешь откатить, никаких действий не нужно".
  
• elidable=True. Бэкфилл - разовая операция. При squashmigrations Django удалит её из объединённой миграции.
  
• atomic = False на уровне Migration. Без этого каждый .update() всё равно был бы внутри общей транзакции миграции - то есть мы бы не получили никакого выигрыша.

• Миграция блокирует выкатку. Если бэкфилл идёт 6 часов, релизы стоят.
  
• Миграцию нельзя поставить на паузу, перезапустить, мониторить отдельно.
  
• Если разработчик пропустит её локально (migrate идёт слишком долго)

# developers/management/commands/backfill_developer_status.py
from django.core.management.base import BaseCommand
from django.db import transaction
from developers.models import Developer
class Command(BaseCommand):
    help = 'Backfill Developer.status'
    def add_arguments(self, parser):
        parser.add_argument('--batch-size', type=int, default=5000)
        parser.add_argument('--sleep', type=float, default=0.0)
    def handle(self, *args, batch_size, sleep, **options):
        import time
        qs = Developer.objects.filter(status__isnull=True)
        total = qs.count()
        self.stdout.write(f'To backfill: {total}')
        done = 0
        while True:
            pks = list(
                qs.order_by('pk').values_list('pk', flat=True)[:batch_size]
            )
            if not pks:
                break
            with transaction.atomic():
                Developer.objects.filter(pk__in=pks).update(status='active')
            done += len(pks)
            self.stdout.write(f'Done: {done}/{total}')
            if sleep:
                time.sleep(sleep)

python manage.py backfill_developer_status --batch-size 2000 --sleep 0.5

• запускаешь руками, когда нагрузка ниже;
  
• можешь прервать Ctrl+C и продолжить позже (она идемпотентна - берёт только строки с status IS NULL);
  
• параметры (batch_size, sleep) на лету;
  
• легко мониторить - отдельный процесс, отдельный лог.

operations = [
    migrations.AlterField(
        model_name='developer',
        name='status',
        field=models.CharField(max_length=16),  # null=False
    ),
]

ALTER TABLE "developers_developer" ALTER COLUMN "status" SET NOT NULL;

from django.contrib.postgres.operations import AddConstraintNotValid
from django.db import migrations, models
class Migration(migrations.Migration):
    dependencies = [('developers', '0050_previous')]
    operations = [
        AddConstraintNotValid(
            model_name='developer',
            constraint=models.CheckConstraint(
                condition=models.Q(status__isnull=False),
                name='developer_status_not_null',
            ),
        ),
    ]

def backfill_status(apps, schema_editor):
    # Как реализовано ранее
class Migration(migrations.Migration):
    atomic = False
    dependencies = [('developers', '0051_check_status_not_null')]
    operations = [
        migrations.RunPython(
            backfill_status,
            reverse_code=migrations.RunPython.noop,
            elidable=True,
        ),
    ]

from django.contrib.postgres.operations import ValidateConstraint
from django.db import migrations, models
class Migration(migrations.Migration):
    atomic = False  # VALIDATE может быть долгим
    dependencies = [('developers', '0052_backfill_status')]
    operations = [
        # 1. Валидируем CHECK — SHARE UPDATE EXCLUSIVE, совместимо с DML.
        ValidateConstraint(
            model_name='developer',
            name='developer_status_not_null',
        ),
        # 2. Меняем колонку на NOT NULL.
        # На PG 12+ при наличии валидного CHECK NOT NULL операция мгновенна:
        # PG использует существующий CHECK как доказательство.
        migrations.AlterField(
            model_name='developer',
            name='status',
            field=models.CharField(max_length=16),
        ),
        # 3. CHECK больше не нужен (его роль теперь у NOT NULL constraint).
        migrations.RemoveConstraint(
            model_name='developer',
            name='developer_status_not_null',
        ),
    ]

from django_test_migrations.migrator import Migrator
def test_backfill_status_fills_existing_rows(transactional_db):
    migrator = Migrator(database='default')
    # 1. Применяем миграции до состояния "ДО" нашей data-миграции.
    old_state = migrator.apply_initial_migration(
        ('developers', '0050_add_status_field'),
    )
    Developer = old_state.apps.get_model('developers', 'Developer')
    # 2. Создаём данные — как они выглядели до бэкфилла.
    Developer.objects.create(title='Alice', status=None)
    Developer.objects.create(title='Bob', status=None)
    Developer.objects.create(title='Charlie', status='admin')
    # 3. Применяем нашу data-миграцию.
    new_state = migrator.apply_tested_migration(
        ('developers', '0052_backfill_status'),
    )
    Developer = new_state.apps.get_model('developers', 'Developer')
    # 4. Проверяем результат.
    assert Developer.objects.filter(status='unknown').count() == 2
    assert Developer.objects.filter(status='admin').count() == 1
    assert Developer.objects.filter(status__isnull=True).count() == 0
    migrator.reset()

• Тест действительно прогоняет миграцию против БД, а не моки.
  
• Может тестировать reverse: применил A - создал данные - откатился до B - проверил, что данные адекватны.
  
• Интегрируется с pytest-django (фикстура transactional_db).

• pythonmanage.pymakemigrations --check --dry-run - есть ли несгенерированные миграции в коде? Если разработчик поменял модели, но не запустил makemigrations, миграции в проде не будет.
  
• pythonmanage.pymigrate --plan - что именно поедет.
  
• Тесты на data-миграции (django-test-migrations).
  
• (Опционально, для крупных проектов) - pythonmanage.pysqlmigrate <app> <migration> в артефакт CI: ревьюверам удобно сразу увидеть SQL без поднятия локального окружения.

• Запустил sqlmigrate, прочитал SQL глазами. Не смог понять глазами - прогнал нейронкой.
  
• Понимаю, какую блокировку возьмёт PostgreSQL для каждой операции.
  
• Если ACCESS EXCLUSIVE на большой таблице - миграция разделена на безопасные шаги (NOT VALID + VALIDATE, CONCURRENTLY, expand/contract).
  
• Долгие операции в отдельной миграции с atomic = False.
  
• Если есть сомнения - подумать над lock_timeout и statement_timeout
  
• Изменения обратно-совместимы: старый код приложения корректно работает с новой схемой.
  
• Есть план отката: если миграция сломала прод, что мы делаем? (Откатить миграцию? Откатить код? И то и другое?)
  
• Есть бэкап актуальной БД, или это slave с актуальным lag.
  
• На staging миграция прогналась против дампа prod-данных или их объёма.
  
• Время накатывания - не пятница вечер. Не "вот сейчас релиз, и сразу миграция в пиковый трафик".

• FK с CASCADE. ON DELETE CASCADE сам по себе не блокирует. Но DELETE родительской строки берёт ROW EXCLUSIVE на дочерних - на больших таблицах это медленно. 
  
• Изменение choices в Django обычно приводит к AlterField миграции, даже если схема БД фактически не меняется. На PostgreSQL лишние ALTER TABLE могут брать сильные блокировки, поэтому для часто меняющихся choices лучше использовать callable choices (Django 5.0+) либо state-only миграции через SeparateDatabaseAndState.
  
• max_length для varchar. Расширение мгновенно. Сужение - REWRITE. 
  
• AlterField для default. Изменение default=... в Python-коде модели не приводит к изменению default в БД - Django применяет default при INSERT на уровне Python. Но makemigrations всё равно сгенерит AlterField. Это no-op для БД, но лишний ALTER TABLE (мгновенный, но ACCESS EXCLUSIVE).
  
• Кейс с migrate --fake после non-atomic краха. Если ты руками докатил часть SQL, помни: --fake фиксирует запись в django_migrations, но не проверяет, действительно ли применены все операции. Ответственность за консистентность - на тебе. Лучше написать checklist в комментарии PR: "применил руками: ALTER TABLE X, CREATE INDEX Y; запускаю migrate --fake".
  
• Reverse data-миграций. По умолчанию ставим reverse_code=migrations.RunPython.noop - на reverse ничего не происходит. Это нормально для бэкфиллов: смысла откатывать данные нет. Для обратимых преобразований (например, миграции enum) - пишим явный reverse. Не оставляй RunPython без второго аргумента: Django выдаст ошибку при попытке откатить.

• Перед migrate - sqlmigrate. Всегда. На любой миграции в любой ветке. Это бесплатно и спасает от 90% инцидентов.
  
• Малые шаги, отдельные миграции. В идеале одна миграция - одна логическая операция. NOT NULL - это четыре миграции, а не одна. Да, миграций станет много, но их можно будет сквошнуть.
  
• Expand - Migrate - Contract. Любое значимое изменение схемы - это минимум три релиза. Старый и новый код должны уметь работать с одной и той же БД.
  
• Автогенерация Django - стартовая точка, не финальная. На больших таблицах её надо править: SeparateDatabaseAndState, AddIndexConcurrently, AddConstraintNotValid, atomic = False.
  
• Инструменты-минимум: sqlmigrate + тесты data-миграций.
  
• Не забываем про существование  lock_timeout + statement_timeout

• Explicit Locking
  
• ALTER TABLE
  
• CREATE INDEX CONCURRENTLY

• django-test-migrations

• Vinta: Django zero-downtime migrations guide

• Часть 1: Готовимся к миграциям и избегаем конфликтов
  
• Часть 2: Полезные советы и обход типичных подводных камней