Выбор базы данных — одно из первых решений при запуске веб-приложения и одно из самых дорогих, если ошибиться. Перенос данных с одной СУБД на другую на работающем проекте занимает недели и фактически останавливает разработку новых функций. При этом вокруг темы слишком много мифов: кажется, что для каждой задачи нужно «своё» хранилище, а архитектура обязана включать минимум три базы. На практике всё прозаичнее: в большинстве веб-проектов достаточно одного PostgreSQL, а Redis и MongoDB подключаются точечно, когда появляются конкретные причины. Разберёмся, как принимать это решение осознанно.
Три инструмента — три разные задачи
PostgreSQL, MongoDB и Redis часто ставят в один ряд, хотя это принципиально разные инструменты — как отвёртка, молоток и паяльник в одной мастерской. PostgreSQL — реляционная СУБД: данные лежат в таблицах со строгой структурой и связями, что критично для заказов, платежей и пользователей. MongoDB хранит данные как JSON-подобные документы без жёсткой схемы — удобно, когда состав полей постоянно меняется. Redis — хранилище типа «ключ–значение» в оперативной памяти: отвечает за доли миллисекунды, но не предназначен для постоянного хранения больших объёмов. Правильный вопрос не «какая база лучше», а какие операции ваше приложение выполняет чаще всего.PostgreSQL закрывает большинство типовых задач
Если ваш продукт — интернет-магазин, CRM, корпоративный портал, сервис записи или маркетплейс, ядро данных почти всегда реляционное: клиенты связаны с заказами, заказы с товарами, товары со складами. PostgreSQL здесь вне конкуренции: ACID-транзакции гарантируют, что оплата и списание со склада либо произойдут вместе, либо не произойдут вовсе. Сложные отчёты — «выручка по регионам за квартал», «воронка от заявки до продажи» — родная стихия реляционных баз. А главный миф о «жёсткой схеме» давно устарел: тип JSONB позволяет хранить в PostgreSQL гибкие структуры как в MongoDB, сохраняя транзакции и индексы. База бесплатна, работает на любом хостинге и поддерживается огромным сообществом.Когда MongoDB действительно нужна
MongoDB окупает себя там, где данные неоднородны и их структура заранее не известна:- каталоги, где у каждой категории свои наборы характеристик: у смартфона — диагональ экрана, у кроссовок — размерная сетка;
- контент, создаваемый пользователями: отзывы, комментарии, профили с произвольными полями;
- потоки событий и логов, которые пишутся сотнями тысяч записей в сутки;
- MVP с быстро меняющейся моделью данных, где каждая итерация продукта меняет состав полей.
Redis — не замена, а ускоритель
Классическая ошибка — выбирать между PostgreSQL и Redis, как между конкурентами. Redis решает узкий класс задач, где важна скорость: чтение из оперативной памяти занимает меньше миллисекунды — в сотни раз быстрее, чем запрос к дисковой базе. Типовые сценарии:- кэширование «тяжёлых» страниц и результатов запросов — сайт отдаёт данные без обращения к основной базе;
- сессии пользователей и содержимое корзины;
- очереди фоновых задач: рассылки, генерация документов, синхронизация с 1С;
- лимиты запросов к API и защита от подбора паролей;
- онлайн-статусы, чаты, рейтинги в реальном времени.
Чек-лист: пять вопросов перед выбором
Прежде чем соглашаться на архитектуру с тремя базами данных, задайте подрядчику (или себе) пять вопросов:- Структура данных стабильна или будет меняться каждые два месяца? Стабильная — PostgreSQL; по-настоящему хаотичная — смотрим в сторону MongoDB.
- Есть ли в системе деньги: платежи, баланс, взаиморасчёты? Есть — реляционная база обязательна.
- Какая реальная нагрузка ожидается в первый год? Для большинства бизнесов это тысячи, а не миллионы запросов в секунду — и одна СУБД справляется с этим с запасом.
- Кто будет администрировать решение? Каждая дополнительная СУБД — ещё одна экспертиза, которую нужно держать в штате или покупать на стороне.
- Что дешевле за три года: одна зрелая база или связка из трёх с тремя системами бэкапов и мониторинга?
Почему «зоопарк» баз — это дорого
Мода на сочетание нескольких хранилищ пришла из крупных технологических компаний с миллиардами запросов в сутки. В проекте среднего бизнеса три СУБД вместо одной означают больше точек отказа, три подхода к бэкапам, мониторингу и миграциям, более высокие требования к команде. По нашей оценке, сопровождение связки из двух-трёх баз увеличивает стоимость поддержки проекта на 30–50%. Добавляется и трудноуловимый риск: когда одни и те же данные частично живут в PostgreSQL, частично в MongoDB и частично в Redis, рано или поздно они разъезжаются — и разбираться, какая версия «правильная», придётся в самый неподходящий момент. Каждая дополнительная база данных должна появляться под измеримую проблему, а не «на всякий случай».Пример: интернет-магазин на одной базе
Типовой магазин с каталогом на 50 000 товаров, корзиной и онлайн-оплатой спокойно живёт на одном PostgreSQL: товары, заказы, клиенты, отчёты — всё в единой транзакционной модели. Когда трафик вырастает и страницы каталога генерируются медленнее, чем нужно, добавляем Redis для кэша и сессий — это точечная доработка на одну-две недели, а не переписывание архитектуры. MongoDB в этой картине не появляется вообще — и не должна. Так выглядит здоровая эволюция проекта: сначала простое решение под реальную нагрузку, затем точечные усиления там, где метрики показывают проблему.Итог простой. Дефолт для нового веб-приложения — PostgreSQL: он покроет транзакции, отчёты и даже гибкие данные через JSONB. Redis подключается, когда измеримый рост нагрузки требует кэша или очередей. MongoDB берут осознанно — под неоднородные данные и высокую интенсивность записи, а не потому, что «так модно». Главный вопрос, который стоит задать подрядчику до старта разработки: почему выбрана именно эта база и какой показатель станет сигналом добавить вторую. Если хотите, чтобы архитектуру данных вашего проекта спроектировали с запасом, но без лишней сложности, — напишите нам: разберём задачу и предложим решение с обоснованием.