PostHog: когда продуктовая аналитика превращается в ещё один сервер, который надо кормить

PostHog обычно берут как замену Mixpanel/Amplitude, когда нужен self-hosted сбор событий, воронки, ретеншн, feature flags и запись сессий в одном месте. Для команды это удобно: одна схема событий, меньше зоопарка из отдельных SaaS и проще контроль над данными.

Но «open source» тут не означает «поставил и забыл». У проекта нормальная зрелость и активное репо, однако self-host почти всегда тянет за собой ClickHouse, Postgres, очередь, хранилище для записей и регулярную уборку инцидентов. Сам продукт закрывает аналитику, но инфраструктура съедает время девопса и внимание продукта.

Когда брать self-host: если у вас много внутренних событий, нужен контроль над сырыми данными, есть кто будет следить за бэкапами, ретеншном и схемой трекинга. Когда платить SaaS: если аналитика нужна «чтобы видеть базовые воронки», а не становиться отдельным проектом поддержки.

Самая частая ошибка — тащить в PostHog всё подряд. Сначала фиксируйте 10–20 ключевых событий, иначе через месяц получите свалку из дублей, а не аналитику 📉

Если команда не готова обслуживать хранилище и качество событий, PostHog превращается не в экономию, а в дорогой способ купить себе ещё один слой операционки.