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

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

Ключевое различие

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

Почему в бизнес-проектах мы берём PostgreSQL

Причина прозаична: в бизнес-приложениях почти всё связано со всем. Заказ связан с клиентом, позициями, оплатами и доставкой. Через полгода заказчик спросит: сколько повторных заказов у клиентов из определённого города за квартал. В реляционной базе это один запрос, в документной — выгрузка и обработка в коде.

-- Повторные заказы по городам за квартал
select
  c.city,
  count(distinct c.id)                          as clients,
  count(o.id)                                   as orders,
  round(count(o.id)::numeric / count(distinct c.id), 2) as per_client,
  sum(o.total)                                  as revenue
from clients c
join orders o on o.client_id = c.id
where o.created_at >= date_trunc('quarter', now())
group by c.city
having count(o.id) > count(distinct c.id)  -- только там, где есть повторные
order by revenue desc;

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

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

Промежуточный вариант: JSONB

Часто выбор ставится ложно. PostgreSQL умеет хранить документы в поле типа JSONB с индексами и поиском по содержимому. Это позволяет держать стабильную часть данных в столбцах, а изменчивую — в документе, не заводя вторую базу.

create table products (
  id         bigserial primary key,
  sku        text not null unique,
  name       text not null,
  price      numeric(12,2) not null,
  -- Характеристики различаются по категориям товаров
  attributes jsonb not null default '{}'
);

-- Индекс для поиска по содержимому документа
create index products_attributes_idx on products using gin (attributes);

-- Поиск по вложенному полю
select sku, name, price
from products
where attributes @> '{"material": "дуб"}'
  and (attributes->>'width')::int between 60 and 90;

Как решить в вашем случае

1. 01Выпишите основные сущности и связи между ними. Если связей много — берите реляционную базу.
2. 02Сформулируйте пять отчётов, которые понадобятся бизнесу через год. Проверьте, как они выражаются в каждой модели.
3. 03Оцените, насколько различается структура записей. Если различия касаются части полей, используйте JSONB.
4. 04При сомнениях выбирайте PostgreSQL: он закрывает и реляционный, и документный сценарий с приемлемым качеством.