亚马逊买走鸭子，数据库要变天？

过去几天的数据库圈，热闹得有点反常。ClickHouse 公布 CostBench 结果，宣称每美元性能是 Snowflake 的 412 倍；DuckDB 背后的开发公司 Duck Labs 宣布被 Amazon 收购；Vitess 系团队放出 Multigres v0.1 alpha，要把 Vitess 级别的水平扩展能力带给 Postgres。

三件事看似各说各话，主线却只有一个：开源引擎正在重新谈判与云的分成方式，而「每美元性能」成了这张谈判桌上唯一的硬通货。

对买的人来说，这不只是看热闹的时候，更是重新审视自己数据栈账单的时候。

💰 412倍差距：问题不在跑分，在链路

跑分可以质疑，链路没法造假。

先设想一个每个数据团队都熟悉的场景：季度 FinOps 评审会，报表账单被 CFO 当场点名——为什么刷新一个仪表盘，成本比上个季度又涨了三成？数据团队解释是查询量涨了，但没人说得清，钱具体花在了哪个环节。

ClickHouse 的 CostBench 给出的答案很扎眼：同样的负载下，ClickHouse Cloud 的每美元性能是 Snowflake 的 412 倍。更重要的是，这份报告没有停留在数字上，而是把差距拆到了整条链路里——从新数据到达，到快速返回答案，每一段都被摊开对比。

`mermaid

flowchart TD

A --> B["本地列存落盘"]

B --> C

C --> D

E --> F["缓存未命中回源"]

F --> G

G --> H`

这条图其实就是两种架构哲学的分野。传统云数仓把数据放进对象存储，查询时按需拉起计算资源，缓存不命中就回源扫描——灵活，但每一步都在计费，数据新鲜度也要打折。ClickHouse 走的是另一条路：实时摄入、本地列存、向量化执行，把中间环节尽量砍掉，用更「笨」但更快的路径换成本优势。

当然要说清楚：412 倍这个数字出自 ClickHouse 自己的基准测试，立场天然偏向自家，选型时必须打折扣看。但方向性的差距是真实的——当负载是高频写入的实时分析场景，共享存储架构的每查询成本天然吃亏，这不是跑分技巧问题，是架构税。

对买家的判断只有一句话：别信任何一方的 benchmark，用自己真实的数据和真实查询模式去复测，重点测两个指标——每查询成本，和数据从产生到可查询的延迟。

🦆 鸭子进了亚马逊的院子

开源项目的天花板，往往就是它找到金主的速度。

DuckDB 这两年在开发者社区的地位有点像当年的 SQLite——一个塞进笔记本、嵌进 BI 工具、随手就能跑本地分析的嵌入式 OLAP 引擎。很多人第一次体会到「本地跑分析也可以很快」，就是从这只鸭子开始的。

然后是这条消息：DuckDB 的开发公司 Duck Labs 宣布被 Amazon 收购。消息一出，社区第一反应不是庆祝，而是追问同一个问题——那 MotherDuck 怎么办？

MotherDuck 是围绕 DuckDB 做云服务的独立公司，算是「鸭子上云」这条商业化路线的代表。Duck Labs 被亚马逊收走之后，这条独立云化路线的前景立刻打上问号。据社区里的公开讨论看，开发者真正担心的不是引擎本身——DuckDB 的开源属性短期内大概率不会变——而是两件事：一是 AWS 会不会推出托管 DuckDB 服务，直接改变这个生态的分发格局；二是团队并入大厂后，引擎的演进优先级会不会从社区需求转向云厂商的产品规划。

从产业逻辑看，这笔收购瞄准的是数据工具链的「最后一公里」。嵌入式分析是离数据分析师和业务开发者最近的入口，无数报表工具、notebook、本地管道里都跑着 DuckDB。云巨头把这个入口攥在手里，价值不在于引擎本身赚多少钱，而在于锁定了上游工作负载的流向。

对使用方的建议很直接：如果你的关键管道依赖 DuckDB，现在就把退出成本写进技术文档——数据格式、接口抽象、替代方案，做到「明天换引擎也能跑」。不是悲观，是大厂并购后的第一年，什么都可能发生。

🐘 Postgres 的横向扩展难题，有人接了

Postgres 不缺信徒，缺的是横向扩展的梯子。

另一个经典场景：业务涨了十倍，单机 Postgres 的 CPU 和连接数都顶到天花板，DBA 的选项只剩两个——继续垂直扩容直到钱包喊停，或者做分库分表，然后接受接下来每一年的运维噩梦。分片在 OLTP 世界里从来不是产品能力，而是一门手艺，掌握在少数团队手里。

Multigres v0.1 alpha 的发布，针对的就是这块硬骨头。这个项目把 Vitess 级别的能力——水平扩展、高可用、运维简洁性——带到 Postgres 生态。Vitess 本身经过超大规模互联网场景的长期验证，是 MySQL 分布式化这条路上一套被反复打磨过的方案；如今同一套思路移植到 Postgres，等于把 OLTP 侧开源技术栈里最大的一块空缺补上。

这里面的产业逻辑值得展开。云厂商这两年都在推自家的分布式 Postgres 方案，能力是有的，但问题也明确：方案锁定在自家云上，迁移成本极高。Multigres 走的是社区开源路线，意义在于把「分片不再是一门手艺」变成「装上就能用」——你可以在任何基础设施上部署，不必为分布式能力支付云锁定溢价。

当然要泼一盆冷水：v0.1 alpha 距离生产可用还有相当距离，分片、故障恢复、生态兼容，每一项都需要真实负载去磨。但方向是对的，值得大规模使用 Postgres 的团队保持跟踪，在自己的测试环境里养一个分支。

🧭 三条新闻，一个共同答案：开源引擎加上云的分发权

数据库的竞争，已经从功能清单滑向了每一美元能换多少查询。

把三件事放在一张表里看，趋势更清楚：

三个事件，对应开源引擎商业化的三条路径：自建云服务、被云巨头收编、纯社区驱动。

`mermaid

graph TD

A --> B["自建云服务"]

A --> C

A --> D

B --> E

C --> F

D --> G`

这三条路没有绝对的对错，但有明确的约束条件。自建云的前提是引擎性能足够碾压，能把性能优势换算成账单优势——412 倍的故事本质是在给这条路铺路。被收购的前提是入口价值够大，嵌入式引擎天然适合这条路，但代价是独立性。纯社区路线最干净，也最慢，靠的是把企业级难题做成开箱即用的产品来换采用率。

宏观环境下，成本效率已经压过了功能竞赛。企业数据团队的预算没有跟着数据量一起涨，「用更少的钱跑同样的负载」成了采购决策的第一问。这正是这三个事件同时发生的原因：市场在奖励那些把成本曲线压下来的玩家，无论他们选择哪条商业化路径。

🛠️ 给买家的三句话

别信跑分，信你自己的负载。

具体怎么做，三张卡片贴在墙上：

数据Freshness也要一起测。很多场景里，数据从产生到可查询的延迟，比查询本身慢多少更影响业务——这一项在架构选型里的权重，应该和成本一样高。

小结

412 倍的跑分有立场，收购有变数，alpha 版本有待打磨——三件事单独看都有保留意见。但拼在一起，信号非常清晰：数据库市场的评价体系正在从「功能多不多」切换到「每美元换多少性能、多少新鲜度」，而开源引擎是这场切换里最大的变量。接下来一年值得盯三个点：AWS 会不会给 DuckDB 出托管服务、Multigres 能不能跑进生产、以及各大云数仓面对成本质疑拿出什么样的回应。账单不会说谎，谁先把成本曲线压下来，谁就拿到下一轮的入场券。