ClickHouse или PostgreSQL для трекера: где ломается архитектура и почему

ClickHouse или PostgreSQL для трекера: где ломается архитектура и почему

Если трекер пишет много событий, база начинает отвечать не «да», а «как именно». PostgreSQL удобен как OLTP-слой: сделки, статусы, пользователи, настройки, права доступа. Он хорошо держит транзакции, FK, обновления строк и точечные запросы по id.

ClickHouse выигрывает там, где основной паттерн — append-only и тяжёлые агрегации: клики, конверсии, отчёты по GEO, паблишерам, потокам, окна атрибуции. Он лучше переваривает большие объёмы чтения и группировок, но плохо подходит для частых UPDATE/DELETE и логики, завязанной на строгую целостность.

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

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