DuckDB 单机跑完 10TB 数仓基准，跑分的还是个 AI

MotherDuck 的 CEO Jordan Tigani 上周发了篇博客，说他们把 10TB 的 TPC-DS 基准测试跑在了一台机器上。更有意思的是个细节：跑测试的不是他们的工程师，是 Claude——Tigani 原话是「我就让 Claude 去跑基准，没有任何特殊指示」，他自己只负责检查输出有没有出幺蛾子。

单机引擎第一次公开拿出 10TB 量级的成绩，我把它引用的第三方数字挨个核了一遍，基本属实。

这篇博客叫 Bringing the Big Ducks，10 月 28 日发出，核心主张一句话：数据仓库行业里「单机撑不住」的默认假设，在 10TB 这个量级上已经站不住了。

● ● ●

它晒了什么成绩

先说机器。MotherDuck 最大的实例叫 Giga，Tigani 破例透露了规格：一台 192 核、1.5TB 内存的单机。他拿它对标 Snowflake 3XL——按他的说法，一个 3XL 本质上是「64 个 XS 实例穿一件风衣」，64 台固定规格的机器靠网络凑在一起跑查询；Giga 的 CPU 和内存跟 3XL 差不多，但是一台完整的机器。

单机与分布式架构对比

两轮成绩，口径都是 TPC-DS 99 条查询的几何平均（geomean）：

1TB 档（scale factor 1000），Giga 跑出 690 毫秒；小一号的 Mega 实例是 2 秒。对标数字引自 Fivetran 2022 年的基准：Redshift 4.2 秒、Snowflake 2XL 4.9 秒、Databricks 2X 6 秒、BigQuery 6.1 秒。

10TB 档（scale factor 10000），磁盘上 10TB，99 条查询总共扫过 168TB 数据。Giga 成绩 5.6 秒。对标的数引自 Oracle 官网公布的一组第三方数字（2022 年 3 月提供）：Redshift 8 秒、Snowflake 13 秒、BigQuery 20.2 秒、Azure Synapse 22.9 秒。Tigani 还顺手算了一笔账：这 168TB 的扫描量，按 BigQuery 默认计价要花 1000 美元以上。

注意这些全部是 MotherDuck 自报口径的成绩，对标数字则来自别家几年前的发布——这一点他自己也承认，后面细说。

● ● ●

我去核了它引的数字

厂商博客引用第三方数字，第一反应该是查原始出处。我查了。

Oracle 那组 10TB 数字，在 Oracle 官网 MySQL HeatWave 的基准页上，逐字核对：Redshift 8 秒、Snowflake 13 秒、BigQuery 20.2 秒、Synapse 22.9 秒，页面注明是第三方 2022 年 3 月提供的，与 MotherDuck 博文完全一致。这组对标里每家的年成本也一并列着：Snowflake 28 万美元、Redshift 15 万美元、BigQuery 16.3 万美元。数字没被动过手脚。

Fivetran 那组 1TB 数字有问题。我翻了 Fivetran 基准页的完整正文，具体到每家的秒数在图表和原始数据里，正文文字部分查不到 4.2、4.9、6.1 这些数。第三方报道里能查到的摘要口径（每查询冷跑一次、单流不并发）跟 MotherDuck 用的口径也不完全一样。这组数我没法独立核实，采信与否读者自己判断。

另外两个事实核过：Tigani 确实是「Big Data is Dead」的作者，那篇博客 2022 年发出时他在 MotherDuck，此前是 Google BigQuery 的创始工程师之一；DuckDB 2.0 确实上周刚发布，MotherDuck 还没升级，基准跑在 1.5.6 上——Tigani 说要等下个月第一个补丁版本。

● ● ●

这场比武公平吗

Tigani 在文里自己先认了几条，态度算坦诚，但该拆的还得拆。

对标数字是 2022 年的。四年间 Redshift、Snowflake、BigQuery 都换过代，拿今天的成绩比四年前的对手，胜负本身说明不了太多。Tigani 的辩护是反方向的：他跑分用的 DuckDB 1.5.6 也不是最新的，2.0 对大实例有显著性能提升。两边都没拿出最佳状态，这个说法勉强成立。

成绩是热跑取三轮最优。方法论附录写明：首轮冷跑不计分，每条查询取三轮中最好一次。对家 Fivetran 当年为了防缓存是每条只跑一次。缓存友好的热跑对 MotherDuck 有利——它的 FlashCache 就是为热数据设计的。

单流无并发。99 条查询排队跑，没有多用户并发。真实数仓的负载是几十个分析师同时查询，单机在这种场景下的表现，这篇博客没回答。

TPC-DS 的免责声明。Oracle 页面注明这些查询「衍生自 TPC-DS 但不符合 TPC-DS 规范，不能与官方发布结果比较」。各家用的都是衍生版查询，横向比个大概可以，当权威榜单不行。

把这些折扣都打上，剩下的结论其实温和得多：一台单机在 10TB 量级上跟分布式数仓打得有来有回。这个结论没有「单机碾压分布式」那么响亮，但更接近事实。

● ● ●

真正的信号：那条线又挪了

四年前 Tigani 写「大数据已死」，当时 MotherDuck 内部把大小数据的分界线画在 1TB——超过这个数才需要特殊架构。这次他在博客里说，这条线如今至少要画到 10 倍以外：几十 TB 在单机上已经很常规。

线为什么挪了，两个力叠加。硬件端，几百核、上 TB 内存的服务器变成了大路货；软件端，高核数下的代码效率在持续改进，DuckDB 这一年在这些基准上的成绩翻了倍，2.0 又上了一截。硬件给一倍，软件给一倍，分界线就往后退一个数量级。

文章末尾有个值得玩味的自白：MotherDuck 跟自己的一位投资人打了个赌，赌的是他们永远不需要做分布式模式。Tigani 的立场是——需要分布式的负载是少数，而且随着机器变大还在变少；但他也知道有三个进行中的项目在给 DuckDB 加分布式，AI 时代加分布式越来越容易。赌注没揭盅，但话已经说得两面都有了。

● ● ●

什么时候你该信单机

落到选型，这篇博客能用的部分其实很具体。

如果你的数据在几十 TB 以内、查询以交互式分析为主、并发用户不多，单机方案（不管是不是 MotherDuck）在 2026 年是认真选项，不再是玩具。上面那些成绩就是证据。

如果你的负载是高并发、多租户、或者数据在百 TB 以上，这篇博客没给你任何理由换架构——它压根没测这些场景。

如果你就想自己验证，TPC-DS 的全套工具 DuckDB 里就有：tpcds 扩展自带 99 条查询和 dsdgen 数据生成器，10TB 的数据集 Amazon 公开 S3 上就有（redshift-downloads 桶）。Tigani 能让 Claude 跑，你也能。

回到开头那个细节。一家数仓公司的 CEO 把自家最重要的基准测试交给一个 AI agent 去跑，自己只看输出——这件事本身比 5.6 秒那个数字更说明问题：跑基准这件事的门槛，已经低到「会下指令就行」。往后厂商晒成绩会越来越容易，也越来越不值钱；像这次一样能被第三方数字对上的，才算数。

你团队的数据现在多大？1TB 以内，1 到 10TB，还是 10TB 往上？评论区报个数，我想看看这条线到底画在哪。

● ● ●

参考来源

1. 01
   MotherDuck 博客 Bringing the Big Ducks（成绩、机器规格、方法论附录）https://motherduck.com/blog/bigger-ducks
2. 02
   Oracle MySQL HeatWave 基准页（10TB TPC-DS 第三方数字，2022 年 3 月）https://www.oracle.com/mysql/performance-benchmarks/
3. 03
   Fivetran 云数仓基准（1TB 对标数字的原始出处，2022）https://www.fivetran.com/blog/warehouse-benchmark
4. 04
   Jordan Tigani「Big Data is Dead」（2022，分界线 1TB 的原始表述）https://motherduck.com/blog/big-data-is-dead/
5. 05
   DuckDB 2.0 发布公告 https://duckdb.org/2026/10/21/announcing-duckdb-200
6. 06
   HPCwire 对 Fivetran 基准的报道（摘要口径交叉参考）https://www.hpcwire.com/bigdatawire/2022/12/21/fivetran-benchmarks-five-cloud-data-warehouse/