PostgreSQL vs MongoDB для SaaS: модель данных и эксплуатация

Введение. Для большинства B2B SaaS PostgreSQL остаётся default: ACID, отчёты и зрелые паттерны tenancy. Материал для product- и engineering-лидеров, которые принимают решения на горизонте 12–24 месяцев, а не гонятся за хайпом в презентации.

Когда спор Postgres vs Mongo возникает

Большинство срывов в теме «PostgreSQL vs MongoDB для SaaS» начинается не с кода, а с размытого scope: маркетинг обещает одно, продажи фиксируют другое, а ИТ закрывает техдолг третьим приоритетом. В итоге бюджет уходит в интеграции «на скотч» и ручные сверки в Excel. Мы видим это в проектах, где не описаны границы MVP, нет владельца метрик и не зафиксированы SLA на данные между системами.

Мы видели SaaS-проекты, где выбор MongoDB «потому что гибкая схема» на старте оборачивался 20–30% инженерного времени на дистанции года — на ручные агрегации там, где Postgres с JOIN и оконными функциями решил бы задачу одним запросом. Гибкость на старте часто означает отчётность и связи вручную на масштабе.

Модель данных и запросы

Опорный принцип: сначала поток ценности, потом стек. Нарисуйте journey от первого касания до оплаты и поддержки, отметьте ручные шаги и точки отказа. Только после этого выбирайте PostgreSQL и модель данных. Для PostgreSQL vs MongoDB для SaaS мы обычно рекомендуем row-level security / schema-per-tenant vs document model + aggregation pipelines: она даёт предсказуемый TCO и не блокирует масштабирование команды.

Зафиксируйте ADR по ключевым решениям: хранилище, очереди, авторизация, наблюдаемость. Включите в Definition of Done контрактные тесты API, схему событий и политику миграций. SaaS имеет смысл заказывать только когда есть согласованный backlog с приоритетами P0/P1 и измеримые KPI на квартал.

Модель данных нельзя выбрать один раз и забыть — заведите мониторинг медленных запросов с первого дня: pg_stat_statements для Postgres или profiler для Mongo. Без этого узкое место находят не проактивно, а когда клиент жалуется на тормозящий дашборд, и переписывать индексы приходится в проде, а не на code review.

Эксплуатация и бэкапы

Кейс A (billing SaaS). Клиент пришёл с болью: сложные отчёты по подпискам. Мы разбили релиз на три волны: стабилизация данных, автоматизация рутины, персонализация. Через 14 недель SQL + dbt оказались проще, чем Mongo aggregations. Критично было не «переписать всё», а остановить утечку лидов на стыке каналов.

Кейс B (контент-платформа). Другая ситуация: гибкая схема карточек. Здесь сработала обратная стратегия — сначала интеграция с CRM и нормализация справочников, затем редизайн витрины. Итог: Mongo + валидация схемы на приложении ускорили итерации.

Масштаб и стоимость

1. Выбирать MongoDB «потому что JSON», не оценив, сколько отчётности и join-ов реально в продукте.
2. Проектировать multi-tenancy без явного tenant_id в каждой таблице или коллекции — риск утечки данных между клиентами.
3. Индексировать под удобство ORM, а не под реальные паттерны запросов из продакшена.
4. Не тестировать restore из бэкапа — RPO/RTO существуют только на бумаге.
5. Внедрять event sourcing и CQRS «с первого дня» без реальной необходимости в audit trail.

Как выбрать для SaaS

• [ ] Посчитали долю запросов с join'ами и агрегациями в типичном сценарии продукта
• [ ] Спроектировали tenant_id и row-level security (или её аналог) до первой миграции
• [ ] Настроили PITR и хотя бы раз протестировали полное восстановление из бэкапа
• [ ] Провели нагрузочный тест на 10× ожидаемого числа тенантов
• [ ] Вынесли analytics-нагрузку на read replica или отдельный OLAP, не грузят primary
• [ ] Задокументировали data retention и процедуру удаления данных по запросу клиента

Практическая рекомендация

Часто побеждает Postgres + JSONB, а не полный document store. Если нужна внешняя экспертиза — начните с брифа или оценки: так быстрее получить реалистичный план, чем спорить о стеке в вакууме.

• Явный tenant_id везде
• Индексы под реальные запросы
• План миграций и бэкапов

Модель данных SaaS

Для multi-tenant SaaS PostgreSQL чаще выигрывает: транзакции, row-level security, JSONB при необходимости, зрелые миграции. MongoDB уместна при гибкой схеме документов, heavy write analytics или когда команда уже сильна в document model — но связи и отчётность усложняются. Критично спроектировать tenant_id везде и индексы под реальные запросы, не под ORM по умолчанию.

Backup, PITR и тест restore — часть Definition of Done для SaaS-разработки. Event sourcing и CQRS не нужны «с первого дня», unless audit trail — core value. Нагрузочное тестирование на 10× ожидаемого tenant count дешевле, чем экстренный sharding через полгода.

Планируйте миграции схемы с zero-downtime: expand-contract, backfill jobs, мониторинг lock. Для analytics-heavy нагрузок — read replica или OLAP вынесите отдельно, не грузите primary. Шифрование at rest и in transit — baseline для B2B SaaS. Документируйте data retention и удаление по запросу субъекта. Backend-разработка должна включать runbook на restore из backup.

Зафиксируйте лимиты connection pool и max query time в production — типичный источник «медленного SaaS» без видимых ошибок.