Обзор Django: стоит ли он того сегодня?

За восемь месяцев, с декабря 2025 года по август 2026-го, Django выпустил два функциональных релиза и полностью переписал свой график выпусков.

Всё это произошло с фреймворком, чья репутация почти не менялась с 2023 года: Python-фреймворк «со всем необходимым» — продуктивный, со своим мнением, только синхронный и уступающий позиции FastAPI. Ярлык «только синхронный» устарел, а история его популярности сложнее, чем показывают громкие цифры.

Итак, вот мой вывод о том, стоит ли Django того в версии 6.1: вердикт с оценкой, типы проектов, которым он подходит, и те, где FastAPI теперь лучший выбор.

Кратко

Да, с оговорками. Django 6.1 остаётся лучшим выбором по умолчанию, когда админка, аутентификация, формы и ORM составляют большую часть работы, а отставание по асинхронности сократилось настолько, что «только синхронный» больше не повод его отвергать. Он не подходит для одиночного API с высокой конкурентностью и без админки. 4 из 5.

• Вы покупаете именно комплект. ORM, миграции, сессионная аутентификация с правами доступа, слой форм и сгенерированная админка приходят вместе и уже связанными между собой, а не как пять библиотек плюс швы между ними.
• Фоновые задачи — слабое место. Фреймворк Tasks в Django 6.0 даёт вам декоратор и вызов постановки в очередь, но не воркер, поэтому Celery или его аналог остаётся вашим собственным решением.
• С асинхронностью стало намного лучше, и она явно не доделана. Django поддерживает асинхронные представления и асинхронные вызовы ORM, но транзакции в асинхронном режиме не работают. Под WSGI асинхронные представления всё ещё могут выполнять конкурентный асинхронный ввод-вывод внутри запроса, однако преимуществ полностью асинхронного стека запросов вы не получаете: долгие запросы и высокая конкурентность соединений требуют ASGI.
• Планировать дальше 2027 года стало проще. С января 2028 года Django выпускает один функциональный релиз в год, каждый с тремя годами поддержки, а ярлык «LTS» исчезает, потому что такое обязательство теперь получает каждый релиз.
• Подходит для продуктов с обширной админкой и большим объёмом CRUD, а также для небольших команд. Не подходит для одиночного высоконагруженного или потокового API без админки и форм: там FastAPI — более естественный выбор.

Как готовился этот обзор: Это оценка Django 6.1, построенная на собственных примечаниях к релизам и документации проекта, на августовском объявлении Django Software Foundation 2026 года об управлении проектом, на опросах разработчиков JetBrains/PSF 2024 года и Django 2025 года, а также на публикациях названных по имени практиков об их собственном опыте в продакшене. Многонедельного производственного испытания для этого материала я не проводил, и здесь нет никаких бенчмарков: нагрузочного тестирования не было. Django бесплатен и распространяется по лицензии BSD, а у меня нет никаких отношений с проектом.

Что на самом деле изменилось в Django с 2025 года?

Django 6.0 вышел 3 декабря 2025 года со встроенным фреймворком Tasks и другими добавлениями в ядро. Асинхронный интерфейс ORM появился раньше: Django 4.1 добавил асинхронные операции QuerySet ещё в 2022 году. Django 6.1 стал текущей стабильной версией 5 августа 2026 года. Затем, 10 августа 2026 года, проект объявил о переходе на один функциональный релиз в год с января 2028 года, три года поддержки для каждого релиза и отмену ярлыка LTS.

Примечания к выпуску 6.1 подтверждают, что 6.1 поддерживает Python 3.12, 3.13 и 3.14, при этом основная поддержка заканчивается в апреле 2027 года, а расширенная — в декабре 2027-го.

Вместе с этим меняются и номера версий. Они несут год: Django 2028, затем Django 2029 (по крайней мере, на вопрос «какая у вас версия» станет проще отвечать). Три года делятся на один год обычных исправлений ошибок и два года исправлений безопасности и потери данных — а это и есть то, что раньше означало LTS, поэтому ярлык уходит.

Это оставляет неудобное окно для проекта, который стартует сегодня. Django 5.2 — текущая LTS, поддерживается до апреля 2028 года. Django 6.1 — текущая стабильная версия, но её расширенная поддержка заканчивается в декабре 2027-го, примерно за четыре месяца до окончания срока поддержки Django 5.2 в апреле 2028-го.

Итак: погоня за самым долгим сроком поддержки означает старт на 5.2. Желание получить фреймворк Tasks и свежие возможности ветки 6.x означает старт на 6.1 и согласие на более раннее обновление. Ни то, ни другое не ошибка, а неудобный выбор исчезнет, когда в апреле 2027 года выйдет Django 6.2 LTS.

Смену ритма я читаю как хороший знак. Проекты в упадке тихо растягивают свои обещания поддержки — они не перестраивают их публично, с датированным планом. Этот же упростил обязательство, которое и так выполнял.

Что Django по-прежнему делает лучше всех

Заведите проект на Django 6.1 — и у вас уже есть работающая сессионная аутентификация с системой прав, слой форм, который валидирует и отрисовывает, система миграций, привязанная к вашим моделям, ORM и сгенерированная админка, ещё до того, как вы напишете первую функцию. В этом весь смысл, и это та часть Django, которой не понадобилось меняться.

Ценность не в том, что эти части существуют. Она в том, что их проектировали друг под друга. Те же права на уровне моделей питают админку, а изменение модели одним движением порождает миграцию и обновляет форму в админке.

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

Админка — инструмент для сотрудников. Справочник по админке говорит, что рекомендуемое применение админки ограничено внутренним инструментом управления организации и что она не предназначена для построения вокруг неё всего вашего фронтенда. Права на уровне моделей определяют, что сотрудники могут делать внутри, а чтобы вообще туда попасть, требуется is_staff. Отнеситесь к этому как к ограничению — и это хорошее ограничение: вы бесплатно получаете добротный внутренний бэк-офис и не получаете интерфейс для клиентов, так что никому не хочется его выкатить.

Настройки безопасности по умолчанию — вторая половина того же аргумента. Защита от CSRF, параметризация SQL через ORM, экранирование XSS в шаблонах и защита от кликджекинга включены по умолчанию, а не являются тем, о чём опытный разработчик должен не забыть попросить на ревью. Небольшая команда наследует решения людей, прочитавших десятилетие отчётов по безопасности.

Остаётся возраст. Его читают как обузу — я читаю его как аргумент об экосистеме. Django REST Framework существует и скучен ровно в том смысле, в каком хочется, чтобы инфраструктура была скучной.

То же и со зрелыми пакетами для задач, которые всплывают на четвёртом месяце: фильтрация, ограничение частоты запросов, бэкенды хранения, схемы мультитенантности, журналы аудита. А когда задача настолько необычная, что её не покрывает ни один пакет, обычно находится пятнадцатилетняя ветка в рассылке про неё. По широте охвата, думаю, в Python ничто и близко не стоит, и именно эта ось объясняет, почему Django выбирают вообще.

В чём Django не дотягивает

В Django по-прежнему нет полноценной встроенной типизации по всему фреймворку, осторожный темп оставляет пробелы, о которых формула «со всем необходимым» вас не предупреждает, а у фреймворка Tasks из 6.0 нет воркера. Вот три недостатка на версии 6.1. Пробел в типизации раздражает ежедневно, а Tasks меняет вашу схему архитектуры.

Большую часть истории с типизацией вы по-прежнему собираете из сторонних инструментов. django-stubs предоставляет заглушки типов и собственный плагин для mypy, учитывающий динамическое поведение Django. Его текущая документация заявляет полную поддержку mypy и базовую поддержку pyright, pyrefly и ty. Это лучше, чем было раньше, но это по-прежнему отдельный слой совместимости, а не полноценная встроенная типизация в самом Django.

Если вы приходите из фреймворка, построенного вокруг аннотаций типов, это заметный откат в повседневной работе в редакторе.

Осторожный темп — это и цена, и добродетель. Django добавляет вещи аккуратно и поздно, и именно поэтому фреймворк, который вы выучили в 2019 году, вы можете читать сегодня. По этой же причине батарейки заканчиваются там, где заканчиваются: в ядре нет слоя WebSocket, нет планировщика, нет мнения об оркестрации асинхронных задач. Перейдите одну из этих границ — и вы снова собираете всё сами.

Нужен ли Django 6 всё ещё Celery?

Именно Celery — нет. Фреймворк Tasks в Django 6.0 стандартизирует, как задача описывается и ставится в очередь, но сам он поставленную работу не выполняет. В продакшене вам всё равно нужен бэкенд или процесс-воркер, который исполняет задачи; Celery — один из вариантов, а не требование фреймворка. Примечания к выпуску Django 6.0 прямо говорят о границе: Django берёт на себя создание задач и постановку их в очередь, но не предоставляет механизма воркера, а исполнением должна управлять внешняя инфраструктура — например, отдельный процесс или сервис.

Вы получаете интерфейс:

from django.core.mail import send_mail
from django.tasks import task

@task
def email_users(emails, subject, message):
    return send_mail(subject, message, None, emails)

email_users.enqueue(...) отправляет задачу в настроенный бэкенд. Два бэкенда, поставляемые с 6.0, предназначены для разработки и тестирования (то есть не тот, на который вы надеялись). Планирование, повторяемость, повторные попытки и надёжность хранения — всё это вне области применения.

Кевин Ренскерс, практикующий Django-разработчик, сформулировал это резче всех в своём разборе Tasks:

Вместо этого мы получили абстракцию без реализации.

Насчёт формы он прав. Намерение я бы описал иначе. В голосовании Steering Council по DEP 14— предложении по улучшению Django, стоящем за этой возможностью, — Симон Шаретт утверждал, что «это должно быть чем-то, во что подключаются такие фреймворки, как Celery и RQ», а автор предложения описал его как интерфейс фоновых воркеров, а не как среду исполнения. Значит, справедливая критика не в том, что Tasks сломан. Она в том, что он гораздо уже, чем позволяла ожидать формула «со всем необходимым», и закрывает он скучный пробел: код вашего приложения может ставить работу в очередь, не импортируя конкретную библиотеку очередей.

Поэтому закладывайте очередь задач в любой проект на Django 6.1, которому нужны повторные попытки, работа по расписанию или видимость сбоев. Это та же статья расходов, что и до 6.0, и если вы надеялись, что этот релиз вычеркнет её из вашей схемы архитектуры, то нет.

Если вы уже решили, что Django подходит, и предпочитаете не собирать серверный слой с нуля, Django VPS от Cloudzy даёт вам самоуправляемую отправную точку с Django, Gunicorn, Nginx и PostgreSQL плюс root-доступ, когда вам нужны Redis или Celery. Сервер всё равно ваш и эксплуатировать его вам: вы пропускаете настройку с чистого листа, а не операционную ответственность.

ЧИТАТЬ

Как установить Python на VPS-сервере? Пошаговое руководство

Достаточно ли теперь хороша поддержка асинхронности в Django?

Достаточно хороша, чтобы «он только синхронный» больше вас не останавливало, и недостаточно хороша, чтобы строить на ней полностью асинхронный слой данных. В версии 6.1 верны обе половины. Какая из них относится к вам, зависит от того, что вы строите и подаёте ли вы это под ASGI или WSGI, потому что именно этот выбор определяет, получите ли вы полностью асинхронный стек запросов и эффективную работу с долгоживущими соединениями.

Со стороны возможностей спорить не о чем. Каждый метод QuerySet порождающий SQL, имеет асинхронный вариант с префиксом a. Конструкция async for работает по QuerySet, а асинхронные API базы данных включают методы модели вроде asave() и методы QuerySet вроде acreate(). Вы можете написать асинхронное представление, которое ожидает запросы и конкурентные исходящие HTTP-вызовы без обёртки над пулом потоков. По сравнению с тем Django, о котором писали критику «только синхронный», это другой фреймворк.

Поведение решает протокол развёртывания, а не версия фреймворка, и именно это форуму Django приходится объяснять снова и снова. Тематическое руководство по асинхронности утверждает, что под WSGI-сервером асинхронные представления работают в собственном одноразовом цикле событий, поэтому асинхронные возможности использовать можно, но «преимуществ асинхронного стека вы не получите».

Обслуживание сотен соединений без потоков Python, медленная потоковая передача, длинные опросы — всё это требует ASGI. Тот же код, другое поведение по конкурентности, и ничто в фреймворке не подсказывает, какое из них вы получаете.

У этой путаницы долгая жизнь. Пользователь под ником tomcypress открыл ветку на форуме Django с вопросом, почему последовательные запросы к асинхронному представлению не все выполняют свою фоновую работу, и завсегдатай форума KenWhitesell указал ему на цикл событий WSGI. Этот обмен репликами — из 2021 года, и в версии 6.1 в нём ничего не изменилось.

Её к тому же подкрепляют извне. Страница «за и против» о Django на TechVidvan сообщает читателям, что Django «не способен обрабатывать несколько запросов одновременно», а это неверно для Django 6.1 и относится к тем утверждениям, что заканчивают оценку до её начала. Конкурентность — не то, чего фреймворку не хватает, а то, что решает развёртывание.

Жёсткий стоп — это транзакции, и собственная документация Django по асинхронности говорит об этом прямо:

Транзакции пока не работают в асинхронном режиме. Если у вас есть участок кода, которому нужно транзакционное поведение, мы рекомендуем написать этот участок как одну синхронную функцию и вызывать её через sync_to_async().

Та же страница помечает некоторые ключевые части фреймворка как «небезопасные для асинхронности» и не даёт им выполняться в асинхронном контексте, выбрасывая SynchronousOnlyOperation если попробуете. Значит, форма асинхронного приложения на Django 6.1 такова: асинхронные представления и асинхронное чтение с синхронными островками везде, где записи нужна атомарность. Работать так можно, и это не то же самое, что фреймворк, асинхронный по своей природе. Мой вывод по этой оси: заметно лучше, не закончено, и уверенный зачёт для всего, что не ставит конкурентность на первое место.

Сделал ли FastAPI Django неправильным выбором по умолчанию?

Для конкретного и растущего класса проектов — да. Опрос Python-разработчиков 2024 года от JetBrains и Python Software Foundation, собранный в октябре и ноябре 2024 года при участии более 30 000 человек, даёт FastAPI 38 %, Django 35 % и Flask 34 % среди всех респондентов. Среди тех, кто выбрал веб-разработку как основное применение Python, у Django 61 %, у FastAPI 56 %, у Flask 39 %.

Присмотритесь к этому вопросу, прежде чем нести его на планёрку, потому что он с множественным выбором. Респондентов спрашивали, какими фреймворками они пользуются, а не какой они выбрали, и разработчик, который поддерживает монолит на Django и одновременно пишет сервисы на FastAPI, попадает в оба ответа. Это не взаимоисключающие доли рынка, и никаких 38 % рынка тут ни у кого нет. Они показывают раздвоенный сигнал: FastAPI опережал Django среди всех респондентов, тогда как Django по-прежнему опережал FastAPI среди тех, кто использует Python в первую очередь для веб-разработки.

Отдельный опрос по Django добавляет ещё один сигнал — от тех, кто уже пользуется фреймворком. Опрос Django-разработчиков 2025 года, проведённый Django Software Foundation вместе с JetBrains на 4 655 отфильтрованных ответах, собранных с ноября 2024 по январь 2025 года, показал 82 % тех, кто пишет на Django профессионально, 77 % назвавших его своим самым используемым фреймворком и 48 % обновляющихся с каждым стабильным релизом против 40 % годом ранее. Респонденты самоотобранные, так что это описывает текущую базу пользователей, а не рынок. Широта использования и глубина приверженности — разные сигналы, и второе число у Django здоровее первого.

Места, где выигрывает FastAPI, уже и чётче, чем можно решить по разрыву в опросе. Поверхность API, управляемая типами, где ваши модели Pydantic — это слой валидации, а сгенерированная схема OpenAPI — это контракт, обходит Django плюс слой сериализаторов. FastAPI асинхронен по своей природе на уровне запроса, но его собственная документация прямо говорит : операции пути можно писать и так, и так, а обработчик или зависимость, объявленные обычным def , выполняются во внешнем пуле потоков.

А сервис без админки, без форм и без шаблонов тащит батарейки Django как мёртвый груз: вы платите за мнения фреймворка и пользуетесь четвертью из них. Если вы строите именно это, импульс не хайп, и стоит за ним пойти.

Кому стоит выбрать Django?

Берите Django на версии 6.1, когда админка, аутентификация, формы и ORM составляют большую часть предстоящей работы: внутренние инструменты, маркетплейсы, бэк-офисные SaaS. Он подходит и небольшой команде, которой всё это нужно работающим с первого дня, и команде, которой уже сейчас надо знать, как будет выглядеть её окно поддержки в 2029 году.

Продукты, где мнения фреймворка покрывают большую часть реальной работы. Всё, где есть матрица прав доступа и много CRUD за формой входа. Здесь то, что структурные решения принимает фреймворк, — это плюс, а не издержка, потому что эти решения и составляют большую часть того, что вы всё равно строили бы.

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

Команды, уже работающие на Django и планирующие следующие три года. Django 5.2 даёт вам поддерживаемую нижнюю планку до апреля 2028 года, а годовой ритм даёт предсказуемую планку после. Читаемый горизонт поддержки стоит денег при планировании, и редко когда его вручают настолько ясно.

Кому не стоит выбирать Django?

Не выбирайте Django для высоконагруженного или потокового API без админки за ним: FastAPI — более чистый выбор по умолчанию для такой формы проекта. Не выбирайте его, если в этом году вам нужен асинхронный доступ к данным вместе с транзакциями, потому что в 6.1 этого нет. И не выбирайте его в расчёте на то, что батарейки будут выполнять ваши фоновые задачи.

Одиночный высоконагруженный или потоковый API без админки и без форм. Почти ничто из того, в чём Django хорош, для такой формы проекта не является несущим, так что вы бы поддерживали структуру целого фреймворка ради сервиса, которому нужны были маршрутизатор и валидатор.

Команды, которым уже сегодня нужен полностью асинхронный доступ к данным, включая транзакции. Django 6.1 не поддерживает транзакции в асинхронном режиме. Оборачивать записи в sync_to_async() — это законный приём, а не костыль, из которого вы вырастете в этом году, и там, где он неприемлем, это блокер, а не царапина.

Команды, которые читают «со всем необходимым» как покрытие выполнения фоновых задач. Tasks не поставляется с воркером. Если ваш план исходил из того, что 6.0 убрала очередь из вашего стека, в план нужно вернуть очередь, прежде чем вы завяжетесь на этот фреймворк.

Выбор того, какой веб-фреймворк учить первым, — другой вопрос с другим ответом; краткая версия есть в разделе вопросов ниже.

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

Часто задаваемые вопросы