Реляционная база против документной: что выбрать

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

Главное различие — не SQL и JSON

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

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

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

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

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

Когда реляционная база подходит лучше

Связи важнее формы записи

Интернет-магазин редко ограничивается карточкой товара. Есть заказы, позиции заказа, остатки, платежи, возвраты, скидки и права доступа. Эти сущности меняются по разным правилам, но должны оставаться согласованными. Удаление товара не должно случайно удалить историю заказа, а списание остатка не должно пройти без созданной записи об операции.

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

Нужны сложные выборки

Аналитический экран может объединять клиентов, заказы, категории, способы оплаты и возвраты. В реляционной модели такая связь явно видна в структуре. Запрос может быть сложным, но его легче объяснить, протестировать и сопоставить с бизнес-правилом.

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

Когда документная модель даёт преимущество

Объект читается целиком

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

Такой подход сокращает количество преобразований между моделью хранения и моделью API. Но вложенный массив не должен расти бесконечно. История событий, комментарии и логи обычно лучше живут отдельными документами, иначе чтение и обновление одного объекта будут дорожать вместе с его размером.

Структура меняется быстрее схемы

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

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

Цена каждого подхода

Как выбрать базу для нового проекта

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

Что обычно ломается

Реляционная база как универсальный JSON-склад

Хранить весь объект в одном JSON-поле иногда удобно для редко используемых атрибутов. Но если по полю нужно фильтровать, строить отчёты и обеспечивать уникальность, оно постепенно превращается в таблицу внутри таблицы. Схема становится не явной, а запросы — зависимыми от договорённостей в коде.

Документная база как набор связанных таблиц

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

Миграции, которых «не будет»

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

Когда выбирать что

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

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

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

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

Соберите таблицу операций проекта: сценарий, объём результата, частота, требование к согласованности и допустимая задержка. Затем спроектируйте один и тот же сценарий в PostgreSQL 16 и MongoDB 7, загрузите обезличенный набор данных и измерьте p95-задержку, количество запросов, размер индексов и стоимость обновления. Именно эти числа покажут, где выбор базы действительно влияет на продукт.