В чем преимущество PostgreSQL перед MongoDB

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

Умеете ли вы выбирать хранилище под задачу, а не по моде, и знаете ли актуальное состояние обеих баз. Следом обычно спрашивают, когда вы всё-таки возьмёте MongoDB и как бы хранили в PostgreSQL данные с плавающей структурой.

Как отвечать

Сильные стороны PostgreSQL:

• целостность на уровне базы: внешние ключи, UNIQUE, CHECK, строгие типы. Неверные данные не запишутся, даже если в коде баг;
• запросы: полноценные JOIN, оконные функции, CTE, сложная аналитика одним запросом там, где в MongoDB строится многоэтапный aggregation pipeline;
• транзакции: ACID на MVCC, уровни изоляции вплоть до SERIALIZABLE, транзакционный DDL, то есть миграцию схемы можно откатить целиком;
• JSONB: документы можно хранить и в PostgreSQL, с GIN-индексами и операторами поиска по ключам. Это часто закрывает довод про гибкую схему;
• расширения: PostGIS, pgvector, полнотекстовый поиск через tsvector;
• лицензия: PostgreSQL распространяется под свободной лицензией, MongoDB с 2018 года под SSPL, что для некоторых компаний важно.

Для Python-стека добавьте экосистему: SQLAlchemy 2.0 и Alembic для миграций, Django ORM, где PostgreSQL поддерживается штатно, асинхронные драйверы asyncpg и psycopg 3.

Честно назовите и сильные стороны MongoDB: встроенный шардинг, удобство, когда агрегат читается одним документом, быстрый старт без проектирования схемы. Если данные естественно документные и связей почти нет, это разумный выбор.

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

Говорят, что в MongoDB нет транзакций и join. Многодокументные ACID-транзакции появились в версии 4.0, а $lookup существует давно. Правильная формулировка: есть, но это не основной сценарий и стоит дороже.

Говорят «MongoDB быстрее» без условий. Скорость зависит от модели данных, индексов и нагрузки, а не от названия.

Путают отсутствие схемы в базе с отсутствием схемы вообще. Она переезжает в код, в Pydantic-модели и обработку старых форматов документов, а миграции никуда не исчезают.