五个月前，PostHog 使用 DuckDB 重构数据仓库以取代 ClickHouse，旨在解决共享集群在处理长时间建模查询时的瓶颈，并利用其独立的客户实例架构及 Postgres 协议兼容性。然而，随着客户工作负载规模与复杂度的超出预期，团队在过去三个月中再次对系统进行了重新架构，这次不再使用 DuckDB。
DuckDB 的云端扩展困境
DuckDB 作为单节点分析工具表现卓越，但在云端环境中，其本地优势转化为扩展劣势。面对复杂的客户查询，系统被迫增加巨大的实例资源，导致成本过高且查询速度因磁盘溢出而显著下降。此外，在查询执行前确定工作节点规格的交互设计存在缺陷，难以准确预测特定查询所需的 CPU 和内存资源。
技术瓶颈还包括从 S3 拉取大量数据时的同步限制，以及 DuckLake 扩展在分布式场景下的局限性。DuckLake 为保持跨 SQL 数据库的便携性，限制了引擎特定优化。在 PostHog 的规模下，每次提交需重新读取整个目录统计信息，导致单表写入耗时超过三分钟。尽管通过清理无效元数据将写入速度提升了 30 至 50 倍，但数据垃圾不断重新增长，且共享 Postgres 实例的连接开销巨大。
PB 级数据下的维护挑战
PostHog 直接将约 2PB 数据（包含 1 万亿行和 1530 万个快照）迁移至 DuckLake 进行内部测试，而非从小规模逐步增长。在这一量级下，系统出现了诸多难以在 DuckLake 框架内修复的问题。团队不得不在分支中维护补丁，无法快速合并上游更改，这违背了使用开源方案以获得社区协作支持的初衷。
同时，直接提供 Postgres 连接（端口 5432）在大规模场景下面临严峻挑战。处理断线重连、管理 TTL 和空闲连接极其困难，且缺乏高效的 pgwire 负载均衡工具。相比之下，HTTP 协议在 Kubernetes 路由和负载均衡方面更具灵活性。此外，适配层出不穷的 Postgres 客户端及其特异性行为消耗了大量工程资源，偏离了构建核心数据仓库价值的目标。
基于 Trino 与 HogLake 的重建
吸取教训后，PostHog 围绕自有版本的 Trino 重新构建了数据仓库，并创建了开源表格式 HogLake。该方案已在 PostHog 的 PB 级规模下经过测试，确保在向设计合作伙伴交付前的稳固性。团队强调，数据仓库的核心价值在于用户体验，而非底层技术的炒作。目前，PostHog 正在寻找面临数据仓库速度慢或成本高问题的设计合作伙伴，尤其是拥有海量数据查询需求的企业。