PostHog 替代方案：何时该继续用 PostHog，何时该换成 Gurulu

PostHog 赢得声誉实至名归。其产品团队打造了市面上最具公信力的开源分析工具之一：自动采集、会话回放、功能开关、实验，以及一个 SQL 查询接口，全部基于一份 MIT 风格的许可证，让你可以自托管整套技术栈。对于某一类团队——通常是以工程为主导、拥有真正的平台小组、并对掌控自家遥测管道有明确主张的团队——PostHog 确实是正确答案。本文无意劝你放弃这一选择，而是试图坦诚地说明：PostHog 在哪些情形下不再是正确答案，以及彼时应改用什么。

我们有立场偏向：我们打造的 Gurulu 是一款托管型分析平台，与 PostHog 的功能面有大量重叠。这次对比的目的，并不是在每一个勾选项上都宣称功能对等——PostHog 发布得更久，拥有我们尚不具备的功能——而是诚实地梳理出决策依据，让你挑到正确的工具。我们将谈到 PostHog 的优势所在、运营现实在哪里咬人、Gurulu 的纯托管模式带来了哪些不同的取舍，以及如果你决定切换，一次理智的迁移会是什么样子。

PostHog 真正的优势所在

PostHog 在三个维度上同时取胜，这是市面上其他产品无法兼得的：它完全开源，因此你可以审计并 fork 它；它拥有一个单一产品面，把分析、功能开关、实验和回放融为一体，让你无需把四家供应商拼接在一起；而自托管的分发方式意味着你可以把原始事件数据保留在自己的基础设施内部。对于受监管行业（医疗、政府、金融）或在严格数据驻留合同下运营的团队来说，这种组合是任何 SaaS 都很难复制的。PostHog 通过 HogQL 提供的 SQL 访问，也为数据工程师提供了一条通往 ClickHouse 风格原始查询的逃生通道，而托管型供应商通常会把这类能力锁在数仓导出之后。

开源社区也是实打实的。代码仓库很活跃，社区贡献被接纳，公开的路线图让你看得到接下来要构建什么。如果你对一款分析工具该如何演进有强烈主张，PostHog 是少数几款你真能通过提交一个 PR 来影响其走向的产品。这些都不是小事。

运营现实在哪里咬人

自托管 PostHog 的论据，假设了一个本就运行着 Kubernetes、管理着 ClickHouse 集群、并把可观测性基础设施视为一等平台投入的团队。但在实践中，大多数团队并非如此。参考部署需要 Postgres、ClickHouse、Kafka、Redis 和 Zookeeper，外加 PostHog 应用服务本身。任何运维过生产级 ClickHouse 集群的人都明白这意味着什么：分片再平衡、ZooKeeper 协调故障、查询内存压力、副本漂移、触及存储格式的版本升级。PostHog Cloud 消除了其中大部分负担，但那样你终究还是在为托管型分析付费——这就改变了对话的性质。

自托管的运营负荷。 来自以中等规模（每月 1000 万至 5000 万事件）运行自托管 PostHog 的团队的真实反馈显示，每个季度要在基础设施工作上投入一到两个工程师周：ClickHouse 维护、回放存储清理、需要跨服务协调迁移的版本升级。这是实打实的机会成本。如果你的工程团队有 15 人，每季度拿出一个全职当量周投入分析基础设施，大约相当于总产能的 1%–2%，一去不复返。

规模化后的定价。 PostHog Cloud 的定价按事件量分档递增，在你的产品被真正用起来之前看着都还合理。头一百万事件很慷慨；接下来的一千万会贵出一截；会话回放单独计量；功能开关评估有自己的计量器；实验又增加一项支出。当一款成功的产品每月做到 5000 万至 1 亿事件、并开启了回放时，账单就变得相当可观——往往落在每月 2000 至 5000 美元区间，有时更高。如果这是你唯一的分析开支，那没问题，但它会让那些期望开源光环转化为可预测定价的团队感到意外。

会话回放存储。 会话回放是任何分析产品中成本最高的功能，因为原始的 rrweb 录制非常笨重。PostHog 按录制计费并默认采样；在生产环境中，你几乎总会不得不调整采样器以控制成本，这意味着你真正想看的那些回放（罕见的错误场景）最有可能恰好被采样掉了。这不是 PostHog 的 bug，而是物理规律。但它确实塑造了该功能在实践中的可用程度。

Gurulu 的不同之处

Gurulu 是纯托管的——没有自托管的分发版本，我们也不打算做一个。这是一个有意为之的战略选择：每个运行该平台的团队都以相同的方式、在相同的基础设施上运行相同的代码，这意味着我们交付更快、支持更一致、升级路径自动化。如果自托管对你而言是硬性要求，那么 Gurulu 是错误的工具，PostHog 更为合适；这一点我们直言不讳。对其他所有人而言，纯托管模式消除了上文所述的运营税。

定价模型在结构上也不同。Gurulu 的套餐不像 PostHog Cloud 或 Mixpanel 那样按事件量计量；免费档真正实用，付费档按结果计费（受众规模、回放保留窗口、AI 洞察运行次数），而非按单条事件费率。对于每月做到 5000 万事件的产品，账单的算术会得出一个明显不同的数字，且对我们有利。我们还把错误追踪和 CRM 级的联系人层捆绑进同一个平台，因此那些原本用 PostHog 加一个独立错误工具再加一个独立营销交接 CRM 的团队，往往会进一步合并支出。

迁移：真正奏效的做法

分析平台之间的迁移以卡在“完成 60%”而臭名昭著。典型模式是：有人导出了事件模式，另有人写好了新的埋点，然后一个季度过去，两条管道并行运行，没人信任新的那条，项目就这样悄无声息地夭折了。让迁移真正收尾的诀窍是事件映射加双写加明确的切换日期——而不是永久地并行运行。

实操顺序：第一，列出你当前发往 PostHog 的每一个事件，并决定哪些能挺过这次切换（以我们的经验，30%–40% 的遗留事件是无人查询的累赘）。第二，把存活下来的事件映射到 Gurulu 使用的规范事件名（purchase_completed、signup_completed 等），这样你就不会把命名混乱延续进新系统。第三，双写两周——两边都发——并核对总数；正是在这一步你会逮到那些 bug。第四，挑一个日期，把仪表板切过去，停止向 PostHog 写入。回放导出是最棘手的部分：rrweb 数据笨重，而 PostHog 的导出工具并非为批量迁移而设计，因此实操上的答案通常是“在 Gurulu 上从头开始，并把 PostHog 设为只读保留 90 天”，而非回填。

受众对等比看上去要容易。PostHog 的 cohort 与 Gurulu 的受众在概念上完全相同——都是对用户属性和事件历史的一次保存查询——迁移是一次性重建，而非回填问题。如果你依赖 PostHog 的功能开关承载生产流量，那么功能开关的迁移会更复杂；我们建议为功能开关和实验单独安排一个切换阶段，与分析的切换解耦。

一套决策框架

若以下任一条成立，就继续用 PostHog：你有把原始事件数据留在自家基础设施内部的合规要求；你有一个有余力在生产中运维 ClickHouse 和 Kafka 的平台团队；你严重依赖 HogQL 做即席分析；你想要 fork 或扩展该产品。若以下任一条成立，就换成 Gurulu：你的运营现实是团队里没人愿意伺候这套分析技术栈；你在 PostHog Cloud 上的账单已经越过了托管定价开始扎人的门槛；你想在同一个产品里拥有错误追踪和 CRM 级的联系人层，而不必拼接供应商；你想要由 AI 驱动的洞察发现，而不必自己动手写查询。

我们最常见到的路径是：团队在低量级时从 PostHog Cloud 起步，在每月 2000 万至 5000 万事件附近撞上规模化成本悬崖，评估了托管型替代方案，然后做了合并。第二常见的路径是：团队尝试了自托管，在 6 至 12 个月时陷入运营疲劳，于是改用托管产品，而不是继续自己运维 ClickHouse。这两者都不能说明 PostHog 是个糟糕的产品；它们反映的是纯托管与开源自托管所代表的不同取舍。挑那个匹配你实际拥有的团队的方案，而不是你希望拥有的团队。