ClickHouse vs PostgreSQL в трекере: где ломается стек и как не собрать гибридный зоопарк

ClickHouse vs PostgreSQL в трекере: где ломается стек и как не собрать гибридный зоопарк

Если трекер пишет много событий, а читает их редко, ClickHouse закрывает историю лучше: быстрые агрегации, дешёвые группировки, нормальная работа на больших объёмах логов и конверсий. Но у него слабее точечные обновления, сложнее транзакционная логика и нельзя бездумно строить на нём весь control plane.

PostgreSQL удобнее там, где важны связи, ограничения, атомарные апдейты и живые настройки: кампании, юзеры, права, маппинги, очереди, state machine для конверсий. Для этих сущностей нужен предсказуемый CRUD, индексы по точным полям и нормальная изоляция, иначе начинаются гонки и дубли.

Хорошая схема обычно не «или-или», а разделение ролей: PostgreSQL держит конфиг и оперативные сущности, ClickHouse — сырой event stream, отчёты, ретеншн, postback-историю, дедуп по аналитическим срезам. Между ними нужен явный контракт: schema событий, idempotency key, TTL на сырые данные, правила backfill.

Если пытаешься запихнуть всё в одну базу, смотри на симптоматику: отчёты тормозят из-за тяжёлых JOIN, конфиг трекера начинает зависеть от аналитики, а миграции блокируют запись. В таком месте обычно выигрывает не «более мощная БД», а разграничение write path и analytics path.

Выбирай стек так: PostgreSQL — для управления, ClickHouse — для массового чтения и истории. Один отвечает за целостность, второй — за скорость анализа.