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

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

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

PostgreSQL удобен там, где важны связи, транзакции и предсказуемая логика: пользователи, кампании, правила, биллинг, права доступа, очереди задач. На нём проще строить CRUD-часть и админку, но при росте событийного потока он начинает упираться в IOPS, индексы и вакуум.

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

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