Обзор Django 6.1: режимы загрузки полей, MAILERS и Django 2028

Django 6.1 вышел 5 августа 2026 года, но актуален именно сейчас по двум причинам. Во-первых, 6.1 больше не поддерживает PostgreSQL 14, а сама 14-я ветка PostgreSQL перестаёт получать исправления 12 ноября 2026 года. Во-вторых, Django меняет систему нумерации: версия, которая планировалась как 7.0, будет называться Django 2028. Обзор для проектов на Python и Django — CRM, личных кабинетов, внутренних сервисов.

Главное в Django 6.1

Режимы загрузки полей. `QuerySet.fetch_mode()` управляет тем, что происходит при обращении к незагруженному полю:

• `FETCH_ONE` (по умолчанию) — догружает поле для одного объекта, как раньше;
• `FETCH_PEERS` — догружает поле сразу для всех объектов из того же запроса, как `prefetch_related()` по требованию. По документации, это превращает классическую проблему N+1 запросов в 2 запроса;
• `FETCH_RAISE` — выбрасывает исключение, чтобы поймать случайные запросы на этапе разработки.

Удаление на уровне базы. `ForeignKey.on_delete` теперь принимает `DB_CASCADE`, `DB_SET_NULL`, `DB_SET_DEFAULT`: удаление выполняется средствами SQL, без загрузки объектов в Django. Цена — сигналы `pre_delete` и `post_delete` при этом не срабатывают.

MAILERS. Несколько именованных почтовых бэкендов, как `CACHES` и `DATABASES`: например, отдельный для транзакционных писем и для рассылок. Пока это опция, но в Django 2028 `MAILERS` заменит `EMAIL_BACKEND` и настройки `EMAIL_*`.

Безопасность. Число итераций PBKDF2 для паролей выросло с 1 200 000 до 1 500 000, появился тег `csp_nonce_attr` для политики CSP, подписанные cookie используют однозначную схему соли.

Было и стало

Пример: админка интернет-магазина

Типичная картина в проектах на Django: страница списка заказов в админке открывается несколько секунд. Причина — для каждой строки отдельный запрос к базе за клиентом, способом доставки и статусом оплаты. При 100 заказах на странице это 300 лишних запросов. Раньше это лечили ручной расстановкой `select_related` и `prefetch_related` по всему коду.

В Django 6.1 к этому добавляется `fetch_mode(FETCH_PEERS)`: связанные объекты подтягиваются пачкой при первом обращении. А в админке `list_select_related` теперь выбирает только те внешние ключи, которые реально выводятся в `list_display`. Плюс режим `FETCH_RAISE` в тестах сразу показывает новые места, где кто-то случайно добавил запрос в цикл.

Для владельца бизнеса это выглядит просто: внутренние страницы начинают открываться быстрее, а сервер базы данных нагружается меньше — без смены железа.

Что может сломаться

• PostgreSQL 14, MySQL ниже 8.4, MariaDB ниже 10.11, SQLite ниже 3.37.0 больше не поддерживаются.
• Кеш. Ключи кеша для страниц с Vary и фрагментов шаблонов изменились: первый запрос после обновления будет промахом кеша — возможен кратковременный рост нагрузки.
• first() и last() больше не добавляют сортировку по первичному ключу, если `order_by()` её сбросил.
• Почта. Передача `fail_silently` и учётных данных вместе с `connection` теперь вызывает ошибку, заголовок Bcc в `headers` — тоже.
• Псевдонимы в SQL теперь в кавычках: сырой SQL со смешанным регистром может потребовать правки.
• Админка: удалён класс `wide`, хлебные крошки стали списком `<ol>`.

Сроки поддержки и новая нумерация

По заметкам к выпуску, основная поддержка Django 6.1 — до апреля 2027 года, расширенная — до декабря 2027 года. Django 6.0 после выхода 6.1 получает только исправления безопасности и потери данных — до апреля 2027 года.

С 2028 года Django переходит на календарную нумерацию: версии, которые планировались как 7.0 и 7.1, будут называться Django 2028 и Django 2029. Предупреждения об удалении переименованы соответственно.

Что делать

1. Проверьте версию PostgreSQL: если 14 — обновление базы до 15+ нужно и для Django 6.1, и потому что поддержка PostgreSQL 14 заканчивается 12 ноября 2026 года.
2. Обновляйте Django в отдельной ветке и запускайте тесты с включёнными предупреждениями об устаревании.
3. Попробуйте `FETCH_RAISE` в тестах — он покажет места с лишними запросами к базе.
4. Начните переводить почтовые настройки на `MAILERS`, пока это не стало обязательным.
5. Запланируйте обновление на время с низкой нагрузкой: после смены ключей кеша первые запросы будут медленнее.

Наше мнение

Мы считаем Django 6.1 одним из самых практичных релизов последних лет: `FETCH_PEERS` решает проблему N+1, из-за которой тормозят многие админки и личные кабинеты, почти без изменений кода. Что мы советуем клиентам: использовать обновление как повод закрыть устаревшую базу данных и пройтись по медленным страницам. Связанные проблемы с нагрузкой на PostgreSQL мы разбирали в статье о соединениях после масштабирования.