Огляд 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 закінчується, робить безпечним початок роботи з ним: описані вище виходи видно до того, як ви зобов'яжетеся, а не виявляються потім.

Часті запитання