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

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

Осознаёте ли, что ORM это удобство в обмен на контроль над запросами, и умеете ли называть конкретные проблемы, а не абстрактную «производительность». Плюс понимаете ли разницу подходов: в Django ORM встроен и тянет за собой полфреймворка, FastAPI не навязывает ничего.

Как отвечать

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

Минусы: сгенерированный SQL легко сделать неоптимальным, не видя его; ORM прячет само количество походов в базу; сложные аналитические запросы с оконными функциями, CTE и специфичными для PostgreSQL возможностями выражаются громоздко, и честнее написать SQL руками.

Django: ORM исторически синхронный, асинхронные обёртки методов есть, но модель соединений и транзакций осталась синхронной. QuerySet ленивый, и следом почти наверняка спросят про select_related и prefetch_related.

FastAPI: своей ORM нет, обычно берут SQLAlchemy, часто с асинхронным движком, и Alembic для миграций. Свобода выбора оплачивается тем, что жизненный цикл сессии вы настраиваете сами, обычно зависимостью на запрос.

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

Не называют проблему N плюс один запрос. Это главный практический минус ORM, и лечится он предзагрузкой: select_related через JOIN, prefetch_related отдельным запросом, в SQLAlchemy joinedload и selectinload.

Считают, что ORM защищает от инъекций полностью. Как только в ход идут raw, extra или text() со склейкой строки, дыра открывается ровно та же самая, что и в чистом SQL.

Зовут синхронный ORM внутри async def обработчика. Цикл событий блокируется целиком, и весь выигрыш асинхронного фреймворка пропадает. Нужен либо асинхронный драйвер, либо явный вынос вызова в пул потоков.