ClickHouse или PostgreSQL для трекера: где база начнёт тормозить раньше

ClickHouse или PostgreSQL для трекера: где база начнёт тормозить раньше

Если трекер живёт на сыром клике, показах, postback и логах по каждому переходу, выбор БД решает больше, чем фронт. ClickHouse тянет потоковые вставки и тяжёлые отчёты: агрегаты, срезы по GEO/UA, воронки, дедупликацию по событиям. PostgreSQL удобнее там, где важны транзакции, связи между сущностями и частые точечные UPDATE/DELETE.

Схема «всё в одной базе» обычно ломается на смешанной нагрузке. Сначала начинают проседать отчёты, потом блокируются записи, а дальше любой reindex или vacuum превращается в окно деградации. Для трекера это критично: конверсия может прийти с задержкой, а UI уже показывает пустые или неполные данные.

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

Самая частая ошибка — пытаться заставить PostgreSQL быть аналитической витриной. Вторая ошибка — держать в ClickHouse то, что требует строгих транзакций и уникальности на запись. Разделяйте OLTP и OLAP на уровне модели данных, а не после того как начались лаги.

Итог простой: для трекера PostgreSQL — про контроль и консистентность, ClickHouse — про объём и скорость чтения. Чем раньше вы разведёте эти роли, тем меньше шанс, что база станет узким местом.