Прямой ответ
Коротко: Django — когда нужен продукт целиком (админка, аутентификация, ORM, миграции, шаблоны — «из коробки» — стартап-МВП/контент-сайт/внутренний портал — скорость до первого релиза), FastAPI — когда нужен API (высоконагруженный/строго типизированный/документируемый — микросервис, ML-обвязка, публичный API — контроль над каждым слоем); главное различие — философия: Django — batteries-included (решения за вас: свой ORM, свой auth, свой админ — конвенции — меньше выборов, быстрее старт, «рельсы»), FastAPI — конструктор (сам фреймворк — маршрутизация/валидация/OpenAPI; ORM/auth/миграции — ваш выбор: SQLAlchemy/Alembic/что угодно — гибкость, больше решений, ответственность на вас); критерии, которые реально решают: (1) нужна ли админка — нужна — Django (встроенная admin — дни вместо недель; у FastAPI — только самописная/сторонняя — админка — часто недооценённый аргумент); (2) API-first или сайт — чистый API с OpenAPI-контрактом — FastAPI (автоматическая документация из коробки — Pydantic-схемы — валидация — «дока всегда актуальна»); серверные шаблоны/формы — Django; (3) асинхронность — оба умеют (Django — async-вьюхи с 4.x, FastAPI — async-first) — но: Django-ORM в async — частично (sync_to_async-обёртки — зрелость растёт, не идеал), FastAPI+SQLAlchemy async — полный цикл — реально IO-bound высоконагруженный API — FastAPI ровнее; CPU-bound «асинхронность» не спасает вовсе (GIL — воркеры); (4) ORM — Django ORM (активный рекорд, integrated, миграции из коробки) против «ваша ORM» у FastAPI (SQLAlchemy — мощнее/гибче, но +Alembic руками — миграции — сессии); (5) экосистема/найм — Django — 15+ лет, тонны пакетов (auth-провайдеры, CMS-надстройки, DRF), «джуна найти проще»; FastAPI — моложе, но растёт быстрее всех (по опросам — топ роста), async-стек (httpx/asyncpg) — современный; (6) производительность — FastAPI/Starlette легче (меньше слоёв — raw-запросы быстрее — десятки процентов на простых эндпоинтах) — но 90% приложений упираются в БД/сеть, не в фреймворк — «выберу FastAPI, будет быстрее» — обычно ложная мотивация (архитектура/индексы решают — профилирование); гибрид — частый правильный ответ: Django-монолит (админка+сайт+auth) + отдельные FastAPI-сервисы (ML-инференс, высоконагруженные эндпоинты — микросервисы — не «или», а «что где»); антипаттерны выбора: «FastAPI, потому что модный» (получите админку-самопис и миграции-вручную для CRUD-панели), «Django, потому что знаком» (для ML-обвязки на 3 эндпоинта — тяжёлый каркас); вопрос команде перед выбором: «что будет в сервисе через год — страницы+админка или API+нагрузка» — ответ выбирает фреймворк, не хайп.
Сравнение по критериям
Таблица (сжато — детали ниже): Старт проекта — Django: startproject + admin + auth за час; FastAPI: app + роут за 10 минут, но auth/миграции/админ — дни-недели своей сборки — старт «до работающего CRUD с админкой» — Django быстрее в разы, «до первого эндпоинта» — FastAPI. Валидация/схемы — Django: формы/сериализаторы (DRF) — мощно, но «второй слой» (модель ≠ сериализатор ≠ форма); FastAPI: Pydantic — одна схема на вход/выход/доку (типизация — mypy-дружба — «схема и есть контракт»). Документация API — Django: руками/DRF-пакеты (drf-spectacular — OpenAPI, но надстройка); FastAPI: /docs из коробки — контрактная разработка — для API-first это киллер-фича. Auth — Django: sessions/JWT-пакеты, permissions, группы — готовое (OWASP-гигиена поверх); FastAPI: security-утилиты (OAuth2-хелперы) — но сессии/бэкoffice — собирайте сами. ORM/миграции — Django ORM + встроенные миграции («мака» — одна команда) против SQLAlchemy+Alembic (гибче/строже, руками); Тесты — оба pytest-совместимы (Django — pytest-django, FastAPI — TestClient — тестирование) — паритет. Асинхронность — FastAPI: нативно (async def — весь стек); Django: частично (async-вьюхи, ORM-ограничения) — IO-bound API — FastAPI, «сайт с формами» — sync Django нормален. Админка — Django: встроенная (ModelAdmin — конфигурация — дни → часы — «внутренний инструмент бесплатно»); FastAPI: нет (sqladmin/самопис — админ-паттерны). Websocket/SSE — Django: Channels (надстройка — своя модель); FastAPI: нативно в Starlette (websocket, SSE — проще). Деплой — оба: gunicorn/uvicorn (процессы), Docker — паритет (Django чуть тяжелее образом — мелочь); Обучение/команда — Django: больше документации/ответов/людей (15 лет); FastAPI: современнее стек, async-дисциплина нужна (asyncio-ошибки — «async заразен» — команда должна уметь).
Сценарии: что выбрать под задачу
(1) Контент-сайт/блог/CMS-подобное — Django без обсуждения (админка, SEO-страницы, шаблоны, auth — всё из коробки — «неделя до прода»); (2) Публичный API/мобильный бэкенд — FastAPI (OpenAPI-контракт, типизация, async под мобильный трафик — версионирование/пагинация — паттерны фреймворк-независимы); (3) ML/инференс-сервис — FastAPI (Pydantic-схемы запросов, async-обвязка вокруг блокирующих моделей через пул, лёгкость — ETL-паттерны рядом); (4) Внутренний портал/ERP-подобное — Django (админка+permissions — 70% работы бесплатно); (5) Высоконагруженный API (10k+ RPS) — FastAPI + async-стек (asyncpg/httpx — http-клиенты — полный async без sync-мостов — латентность под нагрузкой ровнее — SLO держится проще); (6) Монолит «всё в одном» — Django (batteries — один кодовый цикл — структура проекта — apps как модули); (7) Микросервис на 5 эндпоинтов — FastAPI (лёгкий каркас — не тащить Django-тяжесть — выбор монолит/микросервисы — отдельный разговор, но фреймворк под размер); (8) Гибрид (реальность крупных) — Django-ядро (админка/CMS/auth) + FastAPI-сателлиты (инференс, webhook-приёмники, realtime) — общая БД через схему/API — интеграционные тесты на стыках; решающий вопрос не «что быстрее/моднее», а «что за продукт» — API-first+нагрузка → FastAPI, продукт-с-админкой+страницы → Django, и то и другое → гибрид (не «переводить», а «разделить по границам» — ADR — решение зафиксировать с критериями — через год вопрос «а почему не X» закрыт документом).
Практический сценарий: маркетплейс — выбор, который пережил три года
Контекст: 2023, команда 4 человека, «маркетплейс нишевых товаров»: каталог (админка — менеджеры заполняют карточки), сайт (SEO — серверный рендер), API для будущего мобильного, планы на «ML-рекомендации когда-нибудь». Спор на старте: «Django — скучно/монолит» против «FastAPI — современно». Решение (по критериям, не по вкусу): админка — критична с первого дня (менеджеры без неё работать не могут — самопис = месяц) → Django-ядро (admin+auth+каталог+SEO-страницы — 6 недель до прода — локальная разработка — Django-admin закрыл 30% продуктовой поверхности); API мобильного (2024): DRF сначала (быстро, но сериализаторы-бойлерплейт, доки — drf-spectacular-надстройка); через год — мобильный трафик вырос, эндпоинты поиска/ленты — высоконагруженные — вынесли FastAPI-сервис (async+asyncpg — read-путь каталога — p95 240 мс → 90 мс при ×4 трафике — профили подтвердили IO-bound — async помог; админка/заказы остались в Django — «переводить всё» не стали — гибрид по границе нагрузка/админка); ML-рекомендации (2025) — третий сервис, FastAPI (Pydantic-схемы фичей, батч-инференс — паттерн из коробки); итоги трёх лет: Django-ядро (5 devs — найм лёгкий — «Django-разработчика нашли за 2 недели»), FastAPI-сателлиты (2 devs — async-стек — обучение команды — async-дисциплина стоила месяца), ошибки: (а) 2023 — пробовали FastAPI для админки — sqladmin-самопис съел 3 недели и заброшен (batteries-ценность Django осознали через боль), (б) 2024 — «FastAPI-монолит» — соблазн перевести всё — остановили микросервис-чеклистом (границы по нагрузке/домену, не «потому что фреймворк другой» — техдолг — «фреймворк-дрейф» без границы — антипаттерн); правило команды теперь: «новый сервис — FastAPI, если API+нагрузка; расширение ядра — Django» — критерий в ADR, споры закрыты; «Django против FastAPI» — ложная дихотомия — правильный вопрос «какая часть продукта какая».
FAQ
Что быстрее — Django или FastAPI? На простых IO-эндпоинтах FastAPI/Starlette быстрее (меньше middleware-слоёв, async-нативность — десятки процентов в синтетике); но реальные сервисы упираются в БД/сеть/бизнес-логику — разница фреймворков тонет (запрос с 5 SQL — время БД, не роутера); «FastAPI = быстрый сервис» — миф без async-стека целиком (async-роут с sync-БД-драйвером — блокировка event loop'а — медленнее sync-Django — asyncio-ошибки); вывод: выбирайте по продукту/эргономике, производительность решают индексы/кэш/архитектура — профилируйте, не гадайте.
**Можно ли начать с Django и «потом перейти на FastAPI»? Миграция фреймворка — почти всегда дороже, чем кажется (auth-механика, ORM-слой, middleware — переписывается всё; реальный путь — не «переход», а вынос сервисов (новые границы — FastAPI, ядро остаётся — сценарий выше); «Django — для прототипа, FastAPI — для прода» — антипаттерн (прототип-код не переносится — выбросить работу); обратное («FastAPI-старт → Django») — ещё реже оправдано (админка-потребность обычно видна с начала); честный выбор на старте по критериям — дешевле любой миграции.
FastAPI без SQLAlchemy — нормально? Да, и часто оправдано: asyncpg/psycopg3 напрямую (raw-SQL — запросы под контролем — нет ORM-магии/ленивых загрузок — для read-heavy API с рукописными запросами — плюс); цена — миграции (Alembic без ORM-моделей — autogenerate не работает — руками — миграции), повторяемость маппинга (строка → Pydantic-модель руками — бойлерплейт — или libraries-помощники); критерий: 2–3 таблицы/простые запросы — raw ок; 20+ таблиц/связи/транзакции — SQLAlchemy окупается; «ORM не нужна» — обычно мнение до первого сложного запроса с 5 JOIN — границы ORM — решать по схеме, не по вкусу.
Что с админкой в FastAPI — совсем никак? Встроенной нет (это сознательная граница фреймворка); варианты: sqladmin (SQLAlchemy-модели — CRUD-админка — покрывает «менеджеры правят справочники» — не Django-admin по гибкости, но 80% нужд), самопис на React+API (полный контроль — месяцы — оправдано при сложном UX админки), отдельный Django-сервис «только админка» (общая БД — админка в Django, бизнес-API в FastAPI — гибрид-минимум — структурный выбор); «админка не нужна» — редкость (внутренние инструменты нужны почти всегда — вопрос «кто пишет» — документация-культура — админка-потребность — первый вопрос к продукту, не последний).
Источники: документация Django и FastAPI — ссылки в шапке.