Выбор СУБД: практическая шпаргалка для бизнеса и инженеров
Представьте, что база данных — это “операционная система” вашей информации. Если выбрать её наугад, вы получите красивый интерфейс поверх узкого горлышка. Я много раз видел, как компании годами “лечат” чужой компромисс: медленные отчёты, блокировки транзакций, космические счета за облачные запросы. Хорошая новость — правильный выбор реально можно сделать за час, если идти по шагам.Зачем правильно выбирать СУБД
Цена ошибки
Ошибочная СУБД — это не просто “медленно”. Это: недоступность при пиках, дорогие переписывания схемы, ночные миграции, перегретые сервера и бюджеты, которые тают быстрее, чем данные в кэше. Перенос потом дороже в разы.Когда “подойдёт что угодно” — миф
Нет универсального двигателя. OLTP любит короткие транзакции и индексы. OLAP — сканы по столбцам и компрессию. JSON — свободу схемы. Кэш — миллисекунды. Смешивать всё “в одном котле” — как грузовик, который пытаются пустить в Формулу-1.
Алгоритм быстрого выбора
7 шагов от требований к shortlist
- Зафиксируйте главный сценарий: OLTP, OLAP, JSON/гибкие структуры, кэш, тайм-серии, HTAP.
- Опишите SLA: RPO/RTO, аптайм, целевые задержки (p95/p99).
- Оцените нагрузку: TPS/QPS сегодня и через год, пик vs среднее.
- Прикиньте объёмы: старт/год/3 года, скорость прироста.
- Выберите модель консистентности: строгая ACID vs eventual.
- Проверьте компетенции команды и доступность поддержки.
- Сверьте стоимость владения (TCO): лицензии, инфраструктура, люди.
Решающее правило OLTP/OLAP/JSON/Кэш
- OLTP → PostgreSQL / MySQL / Oracle / MS SQL / Arenadata Postgres.
- OLAP → ClickHouse / Greenplum / BigQuery.
- Документы/JSON → MongoDB или PostgreSQL (JSONB).
- Кэш → Redis.
- Тайм-серии → TimescaleDB / ClickHouse.
- Импортозамещение → Arenadata Postgres, Ред База Данных, SoQoL.
Типы СУБД и где они сильны
Реляционные (SQL)
Нормализованные схемы, строгие ограничения, транзакции — идеальны для критичных бизнес-операций. PostgreSQL vs MySQL vs Enterprise (Oracle/MSSQL)
- PostgreSQL — универсальный “швейцарский нож”: CTE, JSONB, расширения, репликация, зрелая экосистема.
- MySQL (InnoDB) — простота, скорость чтения, веб-нагрузки; в сложных отчётах и JSON-логике часто уступает PG.
- Oracle/MSSQL — корпоративные фишки, инструменты и производительность, но и серьёзная стоимость лицензий.
- Arenadata Postgres — PG-совместимость плюс отечественная поддержка и кластерные сценарии.

Документные (NoSQL)
Гибкость схемы и быстрая разработка.MongoDB и альтернатива JSONB в PostgreSQL
- MongoDB — родные документы, шардинг “из коробки”.
- PostgreSQL JSONB — когда нужен гибрид: SQL-строгость + документы в тех же транзакциях.
Колоночные (OLAP)
Оптимизированы для сканов по столбцам, агрегаций, компрессии.ClickHouse и облачные аналоги
- ClickHouse — сверхбыстрые аналитические запросы, распределённые кластеры.
- BigQuery/и др. облачные — “заплатил-и-посчитал”, но следите за стоимостью частых запросов.
Ключ-значение
Минимум накладных расходов, максимум скорости.Redis для кэша и временных данных
Сессии, счётчики, очереди, rate-limit — там, где миллисекунды решают.Ключевые критерии выбора
Транзакционность и согласованность
Если деньги и заказы — берите ACID и строгие индексы. Для потоков событий и логов можно ослабить требования до eventual, но осознанно.
Масштабирование и производительность
Вертикальный рост заканчивается быстрее бюджета. Планируйте партиционирование, репликацию и шардинг заранее — даже если “пока не нужно”.
Объёмы, стоимость и команда
TCO = лицензии + железо/облако + люди. Иногда “бесплатный” open-source обходится дороже, если под него нет компетенций.
Импортозамещение и требования регуляторов
Проверьте, какие продукты доступны и поддерживаются локально. Сверьте с требованиями отрасли и внутренней безопасности.
Готовые рецепты по сценариям
Финансы/ERP/CRM (строгие ACID)
PostgreSQL или Arenadata Postgres для транзакций, реплика для чтения, бэкапы + point-in-time recovery. Для тяжёлых отчётов — вынос в ClickHouse и витрины.BI/аналитика/телеметрия (массовые агрегации)
ClickHouse с партиционированием по дате/ключу, колоночные кодеки, материализованные представления для real-time витрин.
Продукты с гибкой схемой (JSON)
Если прототипируете быстро и структура “живая” — MongoDB. Если нужна строгая отчётность и транзакции на всём — PostgreSQL JSONB.Кэш и очереди
Redis: TTL, eviction-политики, кластера. Не путайте с постоянным хранилищем.
Тайм-серии и метрики
TimescaleDB для SQL-команды или ClickHouse для массивных потоков. Включайте ретеншн и downsampling с первого дня.Анти-паттерны и частые ошибки
“Документы вместо нормализации”
Хранить всё “как пришло” удобно до первой сложной выборки. Потом — боль. Нормализуйте там, где есть связи и инварианты.“OLAP на OLTP” и наоборот
Считать суточные отчёты по транзакционной БД — как возить бетон легковушкой. Делайте витрины/реплики или выносите в колоночное хранилище.“Давайте шардинг потом”
Шардинг “вчера” — это неделя. Шардинг “завтра” — это квартал миграций. Проложите путь заранее: ключи, партиции, стратегия ребалансировки.
Итоговый чек-лист
- Какой главный сценарий (OLTP/OLAP/JSON/кэш/тайм-серии/HTAP)?
- Каковы SLA (аптайм, RPO/RTO, p95 задержки)?
- Текущие и прогнозные TPS/QPS, пиковая нагрузка?
- Объёмы на старт/год/3 года и скорость прироста?
- Требуемая согласованность (ACID vs eventual)?
- Шардинг/партиционирование — когда и как?
- Резервное копирование и восстановление (PITR)?
- Безопасность: шифрование, аудит, доступы?
- Импортозамещение/регуляторы: есть ли требования?
- Экосистема: драйверы, ORM, BI-коннекторы?
- Команда: кто будет поддерживать в 24×7?
- TCO: лицензии, инфраструктура, люди, миграции.

Заключение
Выбор СУБД — это не про моду и не про “любимую” технологию. Это про здравый смысл и инженерную дисциплину. Определите главный сценарий, согласуйте SLA, посчитайте стоимость пути через 12–24 месяца — и тогда база станет ускорителем, а не тормозом. Как любит говорить любой прагматичный инженер: “Выбирай то, что упростит жизнь бизнесу завтра, а не впечатлит сегодня”.FAQ
1) Нужно ли сразу делать два контура — OLTP и OLAP?
Не всегда. Но если отчёты тяжёлые и регулярные — да, отделите аналитику (реплика/витрина/ClickHouse), чтобы не мешать транзакциям.
2) Что выбрать для JSON: MongoDB или PostgreSQL JSONB?
MongoDB — быстрее старт и гибче схема. PostgreSQL JSONB — когда важны SQL, транзакции и единая платформа для всего.
3) Можно ли делать кэш на PostgreSQL вместо Redis?
Можно, но не нужно: Redis на порядки быстрее и дешевле в эксплуатации для сессий/счётчиков.
4) Когда стоит думать о шардинге?
Когда расчётная пиковая нагрузка/объёмы через 12–18 месяцев начнут упираться в одну машину. Проектируйте ключи и партиции заранее.
5) Если у нас требования по импортозамещению?
Смотрите Arenadata Postgres, Ред База Данных, SoQoL — проверяйте совместимость по функциям и поддержке, план миграции и наличие локальных партнёров.
