MongoDB против PostgreSQL: что выбрать для проекта

Вы выбираете не между «гибкой» и «строгой» базой

MongoDB и PostgreSQL умеют хранить структурированные данные, поддерживают индексы и транзакции. Поэтому выбор не сводится к формуле «документы для нового проекта, таблицы для серьёзного». Ошибка в модели данных может дорого обойтись в обеих системах: в MongoDB — когда связанные записи приходится согласовывать во многих местах, в PostgreSQL — когда схема и запросы не соответствуют реальному потоку данных.

Сравнение ниже относится к MongoDB 8.0 и PostgreSQL 17. Это не заявление, что именно они — последние версии на момент чтения: перед внедрением сверьте поддержку и документацию выбранного релиза. Речь о выборе модели хранения для нового сервиса, а не о пошаговой миграции.

Главное различие — как устроены данные

В PostgreSQL данные обычно раскладывают по таблицам. Связи между таблицами описывают ключами, а запросы могут собрать нужное представление через соединения. База способна проверять часть правил сама: например, что обязательное поле не пустое, а ссылка указывает на существующую строку.

MongoDB хранит документы в коллекциях. Документ может содержать вложенные объекты и массивы, а данные, которые приложение часто читает вместе, можно держать рядом. Это сокращает число отдельных обращений и удобно, когда структура записи естественно меняется от объекта к объекту. Но «схема гибкая» не значит «схемы нет»: ограничения можно задавать в приложении и на стороне базы.

Отсюда первый практический вопрос: какие данные вы чаще всего читаете и меняете вместе? Если заказ всегда нужен вместе с позициями заказа, их можно моделировать как связанные таблицы или как вложенный массив в документе. Первый вариант лучше выражает отдельные сущности и связи; второй может упростить чтение агрегата, но усложнить обновление отдельных позиций и работу с данными, которые переиспользуются в разных местах.

Сравнение по задачам, а не по лозунгам

Таблица не заменяет проверку конкретных запросов. Например, поддержка JSON в обеих СУБД не делает их одинаковыми: PostgreSQL сохраняет реляционную модель и предлагает JSONB как один из типов данных, а MongoDB строит работу вокруг документов. Успех зависит от того, как устроены фильтры, обновления, индексы и ограничения именно в вашем приложении.

Когда выбрать MongoDB

MongoDB стоит рассматривать, если основной объект приложения — документ с вложенными данными, который обычно читают и меняют целиком или крупными частями. Примеры — каталог с разными характеристиками товаров, профиль с набором настроек или запись события с переменным набором атрибутов. Важно, чтобы данные не требовали постоянной сложной сверки между множеством независимо обновляемых сущностей.

Цена такого решения — ответственность за целостность структуры и связей. Если один и тот же факт скопирован в несколько документов, приложение должно решить, где находится его источник и как обновлять копии. Иначе со временем появятся записи с разными значениями. Шардинг также не «включает масштабирование бесплатно»: нужно продумать ключ распределения и проверить, подходят ли ему реальные запросы.

Когда выбрать PostgreSQL

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

Наличие JSONB полезно, если часть атрибутов меняется или приходит в разной форме. Но складывать туда всё подряд — не автоматический выигрыш: если приложению важны связи, уникальность и проверка значений, полезные свойства реляционной модели легко потерять. И наоборот, широкая таблица не обязана быть единственным правильным способом представить каждый объект.

Выбирайте базу не по тому, как легко сохранить первую запись, а по тому, насколько просто через год поддерживать правила целостности и самые частые запросы.

Как проверить выбор до запуска

1. Опишите главные сущности и правила. Запишите, что должно быть уникальным, какие записи нельзя удалить отдельно и какие изменения должны проходить атомарно. Если ответов много и они связаны, проверьте, насколько естественно правила выражаются в PostgreSQL. Проверка: у команды есть список инвариантов, а не только схема полей.
2. Составьте набор реальных операций. Возьмите несколько самых частых чтений, обновлений и отчётов из требований или логов существующей системы. Не забудьте редкие, но критичные операции вроде возврата платежа или пересчёта остатков. Проверка: у каждого сценария есть пример входных данных и ожидаемый результат.
3. Смоделируйте эти операции в обеих системах. Для MongoDB попробуйте вложенную модель и вариант со ссылками там, где это уместно. Для PostgreSQL сравните нормализованные таблицы с разумным использованием JSONB. Проверка: запросы не требуют скрытого дублирования данных или неожиданной серии обращений.
4. Измерьте на похожем на прод объёме. Используйте одинаковое оборудование, объём и распределение данных, индексы, частоту чтения и записи, число параллельных клиентов. Фиксируйте задержки, нагрузку на CPU и диск, объём хранилища и поведение при росте данных. Универсальных цифр «кто быстрее» здесь нет. Проверка: результаты можно повторить и объяснить условиями теста.
5. Проверьте эксплуатацию и восстановление. Уточните, как команда будет делать резервные копии, проверять восстановление, обновлять версию и наблюдать за ошибками и задержками. Проверка: восстановление проверено отдельно, а не считается успешным только потому, что резервная копия создаётся.

Где выбор ломается

MongoDB: документ разрастается и перестаёт быть агрегатом

Вложенность работает, пока данные удобно читать и обновлять вместе. Если массив постоянно растёт, разные части документа меняются независимо или одни и те же сущности нужны в нескольких контекстах, модель становится неудобной. Перед тем как вкладывать данные, спросите: есть ли у вложенного объекта собственный жизненный цикл и нужно ли искать его отдельно? Если да, вероятно, его стоит моделировать отдельно и проверить сценарии соединения.

PostgreSQL: гибкие данные превращаются в непрозрачный JSON

JSONB помогает хранить переменные атрибуты, но не отменяет проектирование. Если важные для запросов значения спрятаны в разных ключах и типах, их труднее проверять и индексировать предсказуемо. Зафиксируйте, какие поля обязательны, какие участвуют в фильтрации, а какие действительно остаются произвольными.

В обеих системах опасна ставка на «потом добавим индекс». Индекс занимает место и влияет на запись, а неподходящий индекс не ускорит нужный запрос. Проверяйте планы выполнения на реальных запросах и данных; детали диагностики зависят от версии и конфигурации.

Термин: шардинг — распределение частей набора данных по нескольким узлам. Он помогает вынести объём или нагрузку за пределы одного сервера, но требует удачного ключа распределения: неподходящий ключ может усложнить запросы и не дать ожидаемого эффекта.

Что делать дальше

Не выбирайте MongoDB только из-за гибкой схемы, а PostgreSQL — только из-за привычности SQL. Возьмите три главных сценария приложения, опишите для них правила согласованности и протестируйте обе модели на данных, похожих на рабочие. Если приложение уже требует много связей и отчётов, начните с PostgreSQL; если оно оперирует самостоятельными документами, проверьте MongoDB. После выбора следите в проде не за абстрактной «скоростью базы», а за задержками конкретных запросов, стоимостью записи, ростом индексов и тем, сколько логики целостности пришлось вынести в приложение.