Облачные СУБД 2026: PostgreSQL, ClickHouse, Redis, MongoDB — какую базу выбрать под задачу

Когда бизнес задаётся вопросом «какую базу данных выбрать», почти всегда заводят речь о движке. Но на самом деле начинать надо с нагрузки. PostgreSQL, ClickHouse, Redis и MongoDB — инструменты под разные модели данных и разный характер запросов, и попытка использовать один движок во всех сценариях обходится дороже, чем это видится на старте. Ниже — практический разбор: какую СУБД брать под конкретную задачу, как перейти от нагрузки к конфигурации сервера и во сколько обойдётся аренда СУБД в облаке в российском контуре с учётом 152-ФЗ. Речь и про облачные базы данных как технологию, и про DBaaS (управляемые базы данных) как способ их арендовать.

Выбор СУБД начинается с профиля нагрузки, а не с популярности движка

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

OLTP, OLAP, кэш и документы: чем отличаются профили нагрузки

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

• OLTP (транзакционная обработка) — много коротких операций: добавить заказ, списать остаток, обновить профиль. Ключевое — согласованность и ACID (транзакция выполнится целиком либо не выполнится вовсе). Территория реляционных СУБД.
• OLAP (аналитика) — редкие, но тяжёлые запросы по миллионам и миллиардам строк: агрегаты, воронки, отчёты за период. Важна скорость сканирования больших объёмов, а не мгновенная запись строки.
• Кэш и in-memory — данные, которые нужны за доли миллисекунды: сессии, счётчики, очереди, результаты частых запросов. Согласованность вторична, скорость первична.
• Документы и полуструктурированные данные — записи с гибкой, меняющейся схемой: карточки товаров с разным набором атрибутов, логи событий, конфигурации.

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

Экспресс-ориентир: какую базу брать под типовую задачу

Быстрая отправная точка — не догма, а разумное значение по умолчанию.

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

Четыре движка под задачу: PostgreSQL, ClickHouse, Redis, MongoDB

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

PostgreSQL и MongoDB: транзакции, ACID, JSONB против документной модели

PostgreSQL — реляционная СУБД с полноценной поддержкой ACID, внешних ключей, сложных объединений и транзакций любой вложенности. Его сила в целостности: если бизнес-логика не терпит расхождений (деньги, остатки, права доступа), проверка ограничений на уровне базы снимает целый класс ошибок. При этом Postgres давно не «просто SQL»: тип JSONB хранит документы с индексацией по полям, расширения добавляют геоданные, полнотекстовый и векторный поиск. Один экземпляр на разумном железе (8–16 vCPU, быстрый NVMe) уверенно тянет тысячи транзакций в секунду; дальше масштабируют репликами для чтения и партиционированием крупных таблиц.

MongoDB — документная СУБД: единица хранения не строка в таблице, а JSON-подобный документ с произвольной структурой. Это удобно, когда схема заранее неизвестна или меняется от записи к записи, а связи между сущностями неглубокие. Оборотная сторона — за гибкость платят согласованностью: без продуманной схемы документов и индексов база быстро превращается в хранилище, по которому тяжело строить аналитику.

На практике выбор чаще звучит так: MongoDB или JSONB в Postgres. Если документы это лишь часть данных, а рядом есть транзакции и связи, начинайте с PostgreSQL и JSONB, не заводя второй движок. MongoDB оправдан, когда документная модель — основная, и объёмы требуют горизонтального шардирования из коробки (СУБД сама распределяет сложную логику по шардам).

ClickHouse и Redis: колоночная аналитика и in-memory-кэш

ClickHouse — колоночная аналитическая СУБД. Данные хранятся не в строках, а колонках, поэтому запрос, читающий три поля из таблицы с пятьюдесятью, поднимает с диска только эти три. Отсюда высокое сжатие (для типовых логов и событий реально в 5–10 раз) и скорость агрегатов: сканирование сотен миллионов строк за доли секунды. Но ClickHouse — не про точечные обновления и не про транзакции: единичный UPDATE строки здесь противоестественная операция. Это движок отчётов, дашбордов и воронок, а не оформления заказа.

Redis (и его форк Valkey) — in-memory key-value хранилище. Всё держится в оперативной памяти, поэтому отклик измеряется долями миллисекунды, а одно ядро обрабатывает десятки и сотни тысяч простых операций в секунду. Типовые роли — кэш частых запросов, сессии, счётчики, лёгкие очереди, ограничители частоты. Объём упирается в размер RAM, поэтому Redis дорог как основное хранилище и хорош как ускоряющий слой перед основной базой. На старте он обычно не нужен; его вводят, когда профилирование показало конкретное узкое место в повторяющихся запросах.

Сценарии и комбинация баз: почему зрелый стек — это не одна СУБД

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

База под сценарий: магазин, SaaS, аналитика, IoT, ИИ/RAG

• Интернет-магазин. Каталог, корзина, заказы, платежи — PostgreSQL как основа (целостность остатков и оплат критична). Redis — под кэш каталога и сессии. Отчёты по продажам — выгрузка в ClickHouse, чтобы тяжёлая аналитика не конкурировала с оформлением заказов.
• SaaS-сервис. PostgreSQL с разделением данных арендаторов, Redis под сессии и фоновые задачи. Продуктовую аналитику уводят в ClickHouse — её объём быстро превышает то, что разумно держать в транзакционной базе.
• IoT и телеметрия. Поток метрик с устройств — это time-series: много записи, запросы по временным окнам. TimescaleDB (расширение PostgreSQL) или ClickHouse, в зависимости от того, нужны ли рядом транзакции.
• ИИ и RAG. Для поиска по смыслу (RAG — генерация ответа модели с опорой на найденные документы) нужны эмбеддинги и векторный поиск. Расширение pgvector добавляет это прямо в PostgreSQL с индексами HNSW/IVFFlat; когда векторов десятки миллионов, берут специализированную Qdrant.

Принцип за всеми примерами называется polyglot persistence — сознательное использование нескольких хранилищ, каждое под свой профиль. Зрелый стек почти всегда состоит из основной реляционной базы, кэша и аналитического контура, а не из одной «универсальной» СУБД.

Типовые ошибки выбора и их последствия

Ошибки в выборе базы редко стреляют сразу — они проявляются на росте, когда переделывать дорого.

1. Аналитика на транзакционной базе. Тяжёлые отчёты гоняют по рабочему PostgreSQL, пока однажды ночной отчёт не начинает блокировать оформление заказов. Лечится выносом аналитики в отдельный контур с самого начала.
2. NoSQL «потому что модно». Документную базу берут под явно реляционные данные со связями, а потом воспроизводят объединения и целостность в коде приложения — медленнее и с ошибками. NoSQL нужен, когда модель данных действительно документная или ключ-значение.
3. Redis как основное хранилище. In-memory базу нагружают данными, которые должны переживать перезапуск и не помещаются в RAM. Итог — либо потеря данных, либо неоправданно дорогая память.
4. Преждевременное шардирование. Горизонтальное разделение вводят до того, как исчерпан потенциал вертикального масштабирования и реплик, — и получают сложность распределённой системы там, где хватило бы более мощного сервера.

Аренда СУБД в облаке: managed или self-host и как посчитать конфигурацию

Облачные базы арендуют в двух форматах: управляемая база данных (DBaaS), где провайдер отвечает за установку, обновления, резервное копирование и отказоустойчивость, и self-host, где вы сами разворачиваете СУБД на арендованных серверах и управляете ей. Разница — в том, кто несёт эксплуатацию, и это напрямую переводится в деньги.

DBaaS против self-host: из чего складывается совокупная стоимость владения

Сравнивать эти варианты по цене за vCPU бессмысленно — разница прячется в статьях, которых в прайсе нет. Возьмём одинаковую базу для сравнения: кластер PostgreSQL из основного узла и реплики, по 8 vCPU, 32 ГБ RAM, 500 ГБ NVMe, с резервным копированием и PITR (восстановление на произвольный момент времени), горизонт планирования — 3 года. И посмотрим, кто и чем платит за каждую статью.

Ключевая статья расходов — не железо, а люди. На self-host инфраструктура обходится дешевле, но администрирование СУБД (обновления, тюнинг, дежурство по инцидентам, проверка бэкапов) требует ощутимой доли времени DBA. DBaaS переносит эту работу на провайдера, и на среднем масштабе — один-два кластера, команда без выделенного администратора баз данных — экономия на эксплуатации обычно перекрывает наценку за сервис. Перелом наступает на больших и предсказуемых нагрузках: когда в штате уже есть DBA, а узлов десятки, его время всё равно оплачивается, и self-host снова выигрывает по деньгам.

Посчитать для своего проекта можно за один заход. Сложите за выбранный горизонт (обычно 3 года): стоимость ресурсов по прайсу IaaS, плату за хранилище бэкапов, разовое внедрение в человеко-днях и — главное — долю ставки DBA, умноженную на число месяцев. Затем сравните с суммой тарифа управляемого кластера той же конфигурации плюс остаточная доля времени инженера. Разница почти всегда определяется одним числом — тем, какую часть ставки администратора съедает эксплуатация, поэтому именно его стоит оценивать честно, а не по остаточному принципу.

От нагрузки к железу: расчёт vCPU, RAM, IOPS и диска

Как перейти от «у нас такой-то проект» к конкретным цифрам? Разберём на примере интернет-магазина: каталог 300 000 товаров, около 500 000 заказов, пиковая нагрузка 800 запросов в секунду, из них порядка 90% — чтение.

• RAM. Главный принцип OLTP: активная часть данных и индексы должны помещаться в память, иначе база читает с диска и отклик деградирует. Оцениваем «горячий» объём (частые товары, свежие заказы, индексы) — допустим, 40 ГБ. Берём с запасом на рост: 48–64 ГБ RAM.
• vCPU. Ориентир для несложных OLTP-запросов — порядка 100–150 запросов в секунду на ядро. На 800 RPS это 6–8 ядер плюс запас под пики и фоновые операции: 8 vCPU на узел.
• IOPS и диск. Считаем запись: пусть 80 заказов в секунду в пике, каждый порождает несколько операций записи — умножаем на коэффициент 5–8, добавляем контрольные точки и запись журнала. Выходит несколько тысяч IOPS, поэтому диск — только NVMe с запасом; обычный SSD-«эконом» станет узким местом.
• Диск по объёму. Текущие данные плюс индексы (часто +30–50% к объёму таблиц), плюс место под рост и временные файлы. Для описанного магазина разумная точка — 300–500 ГБ.

Дальше эту конфигурацию либо заказывают как управляемый кластер, либо разворачивают на арендованных серверах — и добавляют реплику для чтения (снимает те самые 90% читающих запросов с основного узла) и, при требованиях к отказоустойчивости, второй узел под автоматическое переключение.

Российский контур: 152-ФЗ, отказоустойчивость и импортозамещение СУБД

Для российского бизнеса выбор СУБД и провайдера упирается в требования к данным и в доступность решений. Здесь у облачной аренды есть своя специфика.

Хранение персональных данных: 152-ФЗ, PCI DSS, ГОСТ 57580 на практике

Если в базе есть персональные данные (а они есть почти в любой CRM, магазине или SaaS), включается 152-ФЗ. На практике это значит несколько конкретных вещей.

• Локализация. Базы с персональными данными граждан РФ должны физически находиться на серверах в России. Это исключает хранение в зарубежных облаках и управляемых сервисах вроде Supabase или Neon.
• Аттестованная инфраструктура. Провайдер должен обеспечивать защиту по требованиям ФСТЭК (приказ №21) для нужного уровня защищённости. Проверяемый признак — аттестат площадки и профильные сертификации: ISO 27001, а для платёжных данных — PCI DSS.
• ГОСТ 57580 актуален при работе с финансовыми организациями: требования по нему проще закрывать на инфраструктуре, которая уже под него аттестована.

Практический вывод: часть работы по соответствию 152-ФЗ и ФСТЭК разумно перекладывать на провайдера с готовыми сертификациями и российскими ЦОД. Cloud4U работает в этом контуре — три собственных дата-центра Tier III в России, сертификации ISO 27001, PCI DSS и соответствие 152-ФЗ, что снимает с клиента значительную часть аттестационной нагрузки.

Надёжность и импортозамещение: HA, Multi-AZ, PITR, PostgreSQL для 1С, отечественные СУБД

Отказоустойчивость проще обсуждать на языке бизнес-рисков, чем аббревиатур — за терминами стоят конкретные сценарии простоя и потери данных.

• HA (High Availability) и автоматическое переключение мастера — на случай отказа основного узла. Без него отказ сервера означает простой до ручного вмешательства; с ним резервный узел принимает нагрузку за секунды–минуты.
• Multi-AZ — размещение узлов кластера в разных зонах доступности. Защищает от отказа целой площадки, а не только сервера.
• PITR (восстановление на момент времени) — откат базы на любую секунду в пределах окна хранения. Спасает не от отказа железа, а от логической ошибки: удалили не то, выкатили сломанную миграцию. Обычный бэкап «на вчера» тут теряет данные за целый день.

Отдельная и очень российская тема — PostgreSQL для 1С. После ухода Microsoft SQL Server перевод 1С на PostgreSQL стал массовым сценарием. Нюанс: 1С работает не с ванильным PostgreSQL, а со специально пропатченной сборкой (Postgres Pro или патчи от 1С), а сама база требовательна к дисковой подсистеме и памяти — экономить на IOPS нельзя.

Импортозамещение затрагивает и сами движки. В реестре отечественного ПО есть зрелые варианты: Postgres Pro как основная реляционная база, Arenadata DB и Greenplum для аналитических хранилищ, Tarantool как in-memory платформа, Valkey как открытый форк Redis. Для компаний с требованием использовать ПО из реестра это основной путь — и его стоит закладывать в архитектуру заранее, а не мигрировать под давлением проверки.

Главные выводы

Выбор облачной СУБД идёт не от названия движка, а от профиля нагрузки и сценария: PostgreSQL закрывает транзакции и целостность и вместе с расширениями берёт на себя документы, векторный поиск и time-series; ClickHouse отвечает за аналитику по большим объёмам; Redis ускоряет частые обращения; MongoDB уместен там, где документная модель — основная. На реальном проекте эти контуры почти всегда работают вместе, и зрелая архитектура сочетает несколько баз, каждую под свою задачу.

Решение об аренде — это отдельный расчёт. От объёма данных и нагрузки переходят к конкретным vCPU, RAM, IOPS и типу диска, а выбор между managed и self-host сводят к совокупной стоимости владения за фиксированный горизонт, где главная статья — не железо, а эксплуатация. В российском контуре добавляется обязательный слой: локализация и защита персональных данных по 152-ФЗ и требованиям ФСТЭК, отказоустойчивость под допустимый простой и готовность к отечественным СУБД. Провайдер с ЦОД уровня Tier III и профильными сертификациями закрывает эту часть требований вместе с самой инфраструктурой.