2026 年 11 月 2 日，开源产品分析与数据平台 PostHog 宣布放弃仅使用了 5 个月的 DuckDB 与 DuckLake 数据仓库架构，在闭门重构 3 个月后，全面转向定制版 Trino 和自研开源表格式 HogLake。这记干脆的回旋镖，直接打破了技术社区对单节点引擎平替云数仓的乐观幻想。
回看 2026 年 6 月 29 日，PostHog 工程师 Eric Duong 曾高调发文，宣布在数仓计算层用 DuckDB 替换共享的 ClickHouse 集群（仅保留 ClickHouse 用于事件分析）。当时 ClickHouse 因缺乏基于成本的查询优化器（CBO），难以招架长达数小时的 dbt 建模查询。PostHog 顺应单机分析热潮，为每个客户组织分配独立的、空闲可休眠的 DuckDB 实例，并通过 5432 端口暴露 Postgres 协议。谁也没料到，这套看似轻巧的方案仅存活了两个月，工程团队就不得不在 8 月推倒重来。
2 PB 实测压垮目录：99.4% 的僵尸数据把写入拖慢到 4 分钟
压垮这套新架构的第一块巨石，来自配套的湖仓一体扩展 DuckLake。PostHog 没有循序渐进，而是把自己作为第一个客户（dogfooding），将内部约 2 PB 数据、1 万亿行记录和 1530 万个快照全部灌进了 DuckLake。
DuckLake 的设计初衷是保持简单，让目录 schema 能跨多种 SQL 数据库通用移植。这种通用性在超大规模下变成了致命枷锁。根据 PostHog 在 HogLake 开源仓库披露的故障账本，每次单表提交尝试都会重读整个目录的统计信息，涉及 59,000 张表和 370 万行统计数据，单次尝试耗时 5 至 7 秒，最终导致单表写入耗时高达 190 至 264 秒。
更夸张的是，目录中高达 99.4% 的统计行都属于已被删除（dropped）的旧表。工程团队手动清理这些冗余数据后，写入速度瞬间提升了 30 至 50 倍，但垃圾数据很快又会重新长出来。同时，DuckLake 向底层元数据数据库发起的海量连接，也让共享的 Postgres 实例不堪重负。
其实上游社区早就意识到了隐患。2025 年 6 月 18 日，核心开发者 Mytherin 在 GitHub Discussion #215 中曾解释，不按快照绑定列统计信息是为了防止元数据体积过度膨胀；到了 2026 年 5 月 10 日，仓库成员 dentiny 也在 Issue #1136 中承认保存所有表和列的统计信息难以扩展，提议按表拆分缓存。但 PostHog 为了维持与官方 schema 的 100% 兼容，无法做激进的底层改造，只能背着私有的 fork 补丁艰难维持，完全丧失了使用开源社区项目的初衷。
单机优势在云端反转：无法预判的内存与失控的 5432 端口
如果说目录膨胀还能靠打补丁硬扛，单节点引擎在多租户云端的物理局限则直接动摇了商业根基。PostHog 官网的数据仓库定价是每月前 100 万行免费，超出部分按每行 0.000015 美元阶梯计费。客户花钱买的是开箱即用的托管服务，不应该替平台操心底层机器的内存大小。
在个人笔记本上，DuckDB 内存不足时自动落盘（spill to disk）是保证查询不崩的绝佳特性。但搬到云端后，这套机制成了成本黑洞。平台必须在查询到达前就为单节点 worker 分配好计算资源，而提前预测一条未知复杂 SQL 需要多少 CPU 和内存几乎不可能。如果频繁触发云端磁盘落盘，查询会慢到不可用且账单失控；加上当时 DuckDB 缺乏 S3 异步读取能力，海量拉取远程数据成了另一道卡口。
本地的兜底神技，到了多租户云端往往变成吞噬利润的成本黑洞。
另一个让工程团队始料未及的大坑，是对外直接暴露的 Postgres 协议（5432 端口）。各大新型数据库都喜欢宣传兼容 Postgres，但真正在 Kubernetes 生产环境里大规模运维 pgwire 协议时，麻烦接踵而至：
- 风险.在云原生架构下，维护有状态的 5432 端口长连接代价高昂，AWS NLB 对 pgwire 的负载均衡能力远不如 ALB 对 HTTP 灵活，且海量第三方客户端各自依赖冷门的 Postgres 方言特性，会拖垮小团队的研发精力。
错位 12 天的技术演进，给数仓选型留下什么教训
这段架构折腾里有一个戏剧性的时间差。PostHog 在 8 月至 10 月闭门造车逃离 DuckDB，而就在他们发文前 12 天——2026 年 10 月 21 日，上游刚好发布了 DuckDB 2.0 和 DuckLake 1.1。新版本不仅正式引入了对 Parquet、未压缩 CSV 及 DuckLake 的 S3 异步 I/O 支持，还在 PostgreSQL 上将 10,000 张表的挂载与列表操作提速了 27 倍。
但这并不意味着 PostHog 的撤退是一次误判。哪怕 S3 读取和目录挂载变快，多实例共享 S3 数据依然不等于将多台机器的内存池化给单个大查询使用。面对企业客户不可预测的负载，从第一天就为分布式水平扩展而生的 Trino，依然比单机引擎更适合做托管数仓的底座。
对于正在做技术选型的架构师和云数据库创业者，PostHog 花费 5 个月真金白银买来的教训相当实在：
- 建议.把 DuckDB 留在本地分析、CI 测试或负载边界极清晰的单一嵌入式场景；一旦业务要求对外提供不限规模的黑盒多租户数仓服务，老老实实采用 Trino 这类分布式计算引擎与 HTTP 网关，远比魔改单机工具划算。
接下来值得观察的，是 PostHog 自研的 HogLake 究竟会成长为真正繁荣的开源开放表格式，还是沦为仅服务于其内部定制版 Trino 的专用轮子；而失去这个 2 PB 标杆案例的 DuckLake，也必须在后续版本中彻底补上已删表统计信息的垃圾回收课。