← назад к разделу

Эта развилка отличается от PG vs Mongo: там выбирают основное хранилище, здесь решают, пора ли заводить второе. ClickHouse не заменяет PostgreSQL — он снимает с него аналитическую нагрузку. Поэтому вопрос звучит не «что взять», а «когда добавлять»: слишком рано — лишний stateful-компонент и пайплайн, слишком поздно — аналитика душит прод.

Восемь критериев

1. Объём данных под аналитикой

PG хватает, пока аналитические таблицы — единицы-десятки миллионов строк: правильные индексы, партиционирование и реплика для отчётов закрывают вопрос.

ClickHouse пора, когда счёт на сотни миллионов и миллиарды: события, клики, статусы во времени. PG туда тоже можно затащить — но каждый отчёт будет стоить минуты и дисковый ввод-вывод прода.

Тест: сколько строк просканирует типичный дашборд-запрос? До миллиона — PG; сотни миллионов — ClickHouse.

2. Характер запросов

PG, если «аналитика» — это списки и карточки с фильтрами: последние заказы клиента, заказы за день по магазину. Это OLTP-чтения, ClickHouse в них плох.

ClickHouse, если запросы — агрегаты по длинным периодам: GROUP BY месяц/регион/категория, перцентили, уникальные пользователи, воронки.

3. Свежесть данных

PG, если отчёт обязан видеть транзакцию, закоммиченную секунду назад (касса, остатки, балансы). ClickHouse догоняет прод с лагом пайплайна — секунды-минуты.

ClickHouse, если «данные на пять минут назад» никого не смущают — для дашбордов и BI это норма.

4. Изменяемость данных

PG, если аналитика по сущностям, которые активно правятся, и нужна картина «как сейчас».

ClickHouse, если данные событийные по природе: факт случился и не меняется. Append-only поток — родной жанр MergeTree; правки задним числом — его боль (см. fundamentals).

5. Влияние на прод

PG-реплика годится, пока отчёты не мешают репликации и не требуют своих индексов поверх прод-схемы.

ClickHouse, когда аналитики и BI-инструменты нужно физически изолировать от прода — со своей схемой, денормализацией и предагрегатами, которые в прод-PG не затащишь.

6. Кто потребитель

PG: отчёты строит сам сервис, эндпоинтов мало, формы фиксированы.

ClickHouse: ad-hoc запросы аналитиков, BI-инструменты, продуктовые метрики — непредсказуемые запросы по сырым данным, которые нельзя пускать в прод-базу.

7. Retention и стоимость хранения

PG: история нужна короткая, объём предсказуем.

ClickHouse: годы событий «на всякий случай» — колоночное сжатие 5–20x и TTL с даунсемплингом делают длинную историю дешёвой.

8. Эксплуатационная зрелость

PG: некому эксплуатировать второй stateful-компонент — это честный аргумент отложить ClickHouse, даже когда остальные критерии «за». Пайплайн (outbox → Kafka → консьюмер), мониторинг parts и merges, бэкапы — всё это новые обязанности.

ClickHouse: команда уже держит Kafka и умеет в распределённые паттерны — инкремент небольшой.

Чек-лист «возьми балл»

Балл ClickHouse за каждое «да»:

  1. Аналитические таблицы перевалили за ~50 млн строк или растут на миллионы в день.
  2. Типичный отчёт — агрегат по месяцам/регионам/категориям, а не список.
  3. Лаг данных в минуты приемлем для всех потребителей аналитики.
  4. Данные событийные: вставили и не правим.
  5. Ad-hoc запросы аналитиков/BI уже мешают проду (или их запрещают, чтобы не мешали).
  6. Историю нужно держать годами.
  7. Kafka (или готовность её завести) уже есть.

0–2 — остаёмся в PG: индексы, партиционирование, реплика для отчётов. 3–4 — пограничье: начать с реплики PG и materialized views, готовить пайплайн. 5+ — пора: дальше вопрос только в схеме и пайплайне (моделирование, интеграция).

Типичные ошибки

  • «ClickHouse вместо PostgreSQL». Перенести в ClickHouse OLTP — заказы, остатки, балансы — и обнаружить, что нет ни транзакций, ни дешёвых UPDATE, ни точечных чтений. ClickHouse — дополнение, source of truth остаётся в PG.
  • Кластер на пять миллионов строк. Шардированный ClickHouse под объём, который PG прожуёт с одним индексом. Лишний компонент, пайплайн и эксплуатация — против одного CREATE INDEX.
  • Dual write из Handler-а. Писать в PG и ClickHouse двумя вызовами подряд — потерянные события и рассинхрон гарантированы. Только пайплайн через outbox/CDC (почему — здесь).
  • Зеркалить прод-схему. Перелить нормализованные таблицы PG в ClickHouse как есть и удивляться JOIN-ам. Схема ClickHouse проектируется от запросов: денормализация, события, предагрегаты.
  • Реплика PG «как OLAP». Реплика снимает нагрузку чтения, но не делает строчное хранение колоночным: отчёт за два года будет так же сканировать всё. Реплика — ступень, не конечная станция.

Когда обе базы в одном сервисе — норма

Это не «когда», а целевое состояние: PG держит домен и команды, ClickHouse — события и аналитику, между ними пайплайн с понятным лагом. Ровно та же логика, что и в CQRS: два представления данных под два класса нагрузки. Подозрительно как раз обратное — один сервис, пытающийся выжать оба класса из одной базы на серьёзном объёме.

Что почитать дальше

  • ClickHouse Fundamentals — почему ClickHouse такой быстрый и чем за это платят.
  • Интеграция из Java/Spring — пайплайн PG → Kafka → ClickHouse.
  • PostgreSQL или MongoDB — выбор основного хранилища.
  • Поиск: PG FTS или Elasticsearch — параллельная развилка для поисковой нагрузки.