Какие плюсы и минусы использования ORM в Django и FastAPI

Что проверяют

Знаете ли вы оба стека глубже туториала: где Django ORM экономит недели, где мешает и что меняется с приходом async в FastAPI. Следующий вопрос обычно практический: как вы нашли и убрали N+1 в реальном проекте.

Как отвечать

Сначала общие плюсы ORM: модели как единый источник схемы, миграции, параметризованные запросы, переносимость между СУБД в простых случаях. Потом разделите фреймворки.

Django ORM:

• плюсы: всё из коробки, миграции, админка, ModelForm и ModelSerializer в DRF строятся от моделей. Богатый API: F, Q, annotate, Subquery/OuterRef, bulk_create, select_for_update;
• минусы: жёсткая связка с фреймворком, вне Django его почти не используют. Ленивые queryset легко порождают N+1, а асинхронные методы (aget, async for) есть, но исторически выполняются через sync_to_async в пуле потоков.

FastAPI:

• плюсы: ORM выбираете сами. Обычно это SQLAlchemy 2.0 с AsyncSession и asyncpg или SQLModel, который совмещает модели SQLAlchemy и Pydantic;
• минусы: инфраструктуру собираете сами, это Alembic для миграций, зависимость с сессией через Depends и границы транзакций. Ленивая загрузка связей в async падает с MissingGreenlet, связи грузят явно через selectinload или joinedload.

Закончите критерием выбора: CRUD с админкой и жёсткими сроками разумно делать на Django, нагруженный async API с отдельной схемой данных на FastAPI и SQLAlchemy.

Где спотыкаются

Не умеют диагностировать. Стоит назвать инструменты: django-debug-toolbar, connection.queries, echo=True в движке SQLAlchemy и EXPLAIN ANALYZE на самой базе.

Путают select_related и prefetch_related. Первый делает JOIN и подходит для ForeignKey и OneToOneField, второй отдельным запросом тянет связи «многие ко многим» и обратные.

Держат одну AsyncSession на всё приложение или делят её между конкурентными задачами. Сессия не рассчитана на параллельное использование, её создают на запрос.