执行摘要
MotherDuck 将 DuckDB 的分析性能cloud 协作功能cloud 其性能比 BigQuery 快 4 倍，且通过无服务器、按需付费的定价模式，相比传统数据仓库更能节省成本。在 MotherDuck 宣布其新的欧洲cloud ，其卓越的性能和极具吸引力的定价给我们留下了深刻印象。MotherDuck 现已可集成到您的黄金层中，既能加速数据应用场景的处理，又能同时节省成本。 查看性能基准测试。
引言
在数据分析领域日新月异的格局中，一位新晋玩家正对cloud 仓库的既有格局发起挑战。 MotherDuck，基于 DuckDB的超高速分析引擎，承诺在提供企业级性能的同时，兼具现代数据团队所渴求的简便性和成本效益。但这只“鸭子”真的能与那些根深蒂固的巨头抗衡吗？
我们对 MotherDuck 进行了严格的测试，将其与成熟的竞争对手进行对比，以验证它是否名副其实。我们的发现挑战了当前分析型数据库的现状，并预示着我们在处理cloud数据的方式上将发生根本性的转变。这是一个关于嵌入式数据库如何学会“飞翔”的故事，以及它为何可能彻底改变您的数据架构。
为了吸引这些不断变化的消费者，零售商必须迅速做出调整。
一只正在孵蛋的鸭子
MotherDuck 自称是“面向客户分析与商业智能（BI）cloud ，可扩展至数千兆字节（TB）规模”。要了解cloud 独特之处，我们首先需要关注 DuckDB——这一开源数据库系统在过去几年里悄然革新了数据架构。简而言之，DuckDB 是一个内存型 OLAP SQL 数据库系统。对于那些不常接触数据库术语的人，让我们来解读一下这究竟意味着什么：
OLAP 是“在线分析处理”（Online Analytical Processing）的缩写。 可以将其视为一种专为处理海量数据并快速解答复杂业务问题而设计的数据库。与擅长查找单条记录（例如查询客户订单）的传统数据库不同，OLAP 数据库旨在数秒内扫描数百万行数据并执行复杂计算。它们通过将数据存储在列中而非行中来实现这种速度，从而能够以闪电般的速度分析趋势、计算平均值或汇总整个数据集的销售额。 BigQuery 或 Snowflake 等现代数据仓库采用的正是这种方法。另一方面，还有 OLTP（在线事务处理）数据库，如 PostgreSQL、SQLite 或 MySQL。这些是驱动应用程序的“主力军”，每秒处理数千次单独的读写操作，以确保应用程序平稳运行。 了解更多关于 OLAP 与 OLTP 的区别。
为了真正理解DuckDB的方法究竟有多么具有革命性，我们需要退一步，回顾一下我们是如何走到今天的。20世纪90年代中期，随着雅虎和亚马逊等网络巨头如雨后春笋般涌现，它们遭遇了一道壁垒，这道壁垒彻底重塑了整个数据格局。这些公司被海量数据淹没——也就是我们后来所说的“大数据”——而它们现有的系统根本无法应对。 解决方案是什么？是能够处理这种规模的昂贵且庞大的单体基础设施。但在2000年代硬件成本急剧下降之际，一种新理念应运而生：与其购买更大的机器，为何不使用大量更小、更便宜的机器呢？这种思维催生了MapReduce和Apache Hadoop等分布式系统，这些技术旨在将工作负载分散到商用硬件集群中。 亚马逊顺应这一趋势，将这些分布式技术打包为服务，并推出了首个大型cloud 亚马逊网络服务（AWScloud 。多年来，这已成为行业标准做法：一旦遇到数据问题，就将其分布到更多机器上处理（《数据工程基础》，乔·雷斯 & 马特·豪斯利）。
但真正引人入胜的是：当所有人都忙于构建分布式系统时，幕后却悄然发生着另一场变革。正是那些让分布式计算变得经济实惠的力量，也使单台机器变得无比强大。 如今，你的笔记本电脑凭借更大的内存、更快的处理器和更优质的存储，已经变得极其强大。DuckDB背后的开发者们意识到了这一被忽视的机会：如果我们不再一味地横向扩展，而是能够更智能地纵向扩展，会怎样？如果我们完全无需依赖分布式系统的复杂性，就能解决许多数据问题，又会怎样？
作为全球部署最广泛的数据库引擎之一，SQLite 采用了与传统数据库截然不同的设计思路。PostgreSQL 和 MySQL 作为独立服务器运行，应用程序通过网络连接至它们；而 SQLite 则作为轻量级库直接嵌入到应用程序中。无需配置服务器，没有网络开销，也不需要复杂的设置，只需在应用程序进程内运行纯粹的本地数据库功能即可。这种简洁性，加上卓越的可靠性和速度，使得 SQLite 从移动应用到网页浏览器等各个领域无处不在。
DuckDB 将这一嵌入式理念应用于分析工作负载，证明处理海量数据集并不总是需要分布式系统。正如 SQLite 彻底改变了本地数据存储，DuckDB 也利用本地机器的原始算力，让分析工作重新变得简单。安装只需几秒钟，无需处理任何外部依赖项，您便能立即对数千兆字节的数据运行复杂的分析查询，而无需启动任何cloud 。
DuckDB 之所以特别引人注目，在于它能满足开发者的实际需求。需要分析 Python DataFrame 吗？DuckDB 可以直接对其进行查询。 想要处理 CSV 文件？没问题。这种无缝集成，加上其极速的列式引擎，使 DuckDB 成为分析领域中增长最快的数据库系统之一。其性能提升往往如此显著，甚至会让你质疑当初为何要使用分布式系统。如果您想更深入地了解这种方法背后的技术理念，我们强烈推荐阅读 《使用 DuckDB 进行进程内分析数据管理》 一文。
既然您已经了解了 DuckDB 是什么，接下来我们来谈谈它的局限性。任何技术都存在取舍。DuckDB 只能在单台机器上运行，且每次仅接受一个连接。在当今数据团队构建面向整个组织的cloud解决方案的时代，这无疑是一个相当大的限制。 您无法让多名分析师同时查询同一个 DuckDB 实例，更无法像使用传统数据仓库那样在团队间共享数据集。尽管速度快且简单易用，但 DuckDB 本质上将您的数据锁定在一台机器上，每次仅限一人访问。那么，如何将这个速度极快但本质上仅限单用户使用的数据库，转变为能够服务整个组织的cloud 仓库呢？
学会飞行的鸭子
此时，MotherDuck便登场了。MotherDuck 是一款无服务器数据仓库，它弥合了 DuckDB 的原始性能与现代数据团队协作需求之间的差距。MotherDuck 构建了所谓的“个性化分析数据仓库”，为每位用户提供专属的高性能 DuckDB 实例，同时保持了在整个组织内共享数据的能力。其架构工作原理如下：
在cloud 仓库中，您的笔记本电脑只不过是一个“哑终端”。所有繁重的计算工作都在远程服务器上进行，而您需要按小时付费。但问题在于：您的 MacBook 可能比每小时收费 20 至 60 美元的数据仓库实例运行得更快。MotherDuck 试图通过两种创新方法来利用这种计算能力：
- 基于浏览器的分析工具，将计算直接交由用户处理。
- 双重执行机制能智能地将本地设备的处理能力与cloud 相结合，从而实现比单独使用任一方式都更快的处理速度。
在深入探讨这两种方法之前，我想先说明一点：当应用于您的 黄金层时，MotherDuck 的计算能力才真正大放异彩。对于不熟悉这个术语的人来说，“黄金层”是指经过清理、聚合和增强的最终、可直接用于业务的数据。本质上，这就是驱动您的分析、报告和机器学习的经过打磨的数据集。正是这些数据推动着您最关键的业务决策，因此在此处的性能至关重要。 每位利益相关者都曾饱受仪表盘运行缓慢之苦，每位数据团队成员都曾盯着那个“死亡转轮”等待复杂查询完成。MotherDuck 正视并直接解决了这一痛点。
浏览器内置分析
该方案利用了DuckDB轻量级且便携的设计，使其能够通过WebAssembly（Wasm）直接在浏览器中运行。 不妨将 Wasm 视为一种让复杂软件在浏览器中原生运行的技术：无需插件，无需下载，只需在您最需要的地方提供计算能力。由于 DuckDB 在客户端运行，您无需经历通常向服务器发送请求并等待响应的繁琐过程，即可执行复杂的分析查询。数据处理直接在浏览器中完成，从而消除了网络延迟，并完全减少了对基础设施的依赖。您可以通过尝试 在浏览器中体验 DuckDB。
虽然我们在此不会深入探讨技术实现细节，但值得指出的是，DuckDB-Wasm 表现尤为出色。 这篇论文 中详细阐述的研究表明，它显著优于现有的基于浏览器的解决方案，例如 SQLite 的 Wasm 版本或基于 JavaScript 的数据库 Lovefield。这一巧妙的技术演示预示着我们对分析计算位置的认知正发生根本性的转变。
MotherDuck 提供了这种基于 Wasm 的架构，正如 Mehdi Ouazza 在 这篇文章中所述，MotherDuck 提供了这一基于 Wasm 的架构。这种方法在黄金层分析方面尤为强大。您的数据团队可以处理干净、可直接用于业务的数据，无需担心后端基础设施；处理在本地进行，以实现最大速度；并且通过完全消除网络延迟，您将获得可能最快的响应时间。此外，您还避免了cloud 喜欢对每次查询收取的高昂计算成本。这是一个极具吸引力的方案：更快的分析、更低的成本和更简单的架构，三者合而为一。
双重执行
在黄金层中利用 MotherDuck 的另一种方式是借助其双重执行能力，该能力能够智能地将本地处理cloud 相结合。MotherDuck 不会强制要求整个数据团队共享相同的计算资源，而是为每位用户提供专属的“小鸭子”（duckling）：这是一个独立的无服务器计算实例，可根据用户需求进行弹性扩展。
当您处理分散在不同数据源中的数据时，双重执行的真正优势便得以彰显。 试想，您需要查询存储在 MotherDuck 中的数据，将其与 S3 中的文件结合，并联接本地笔记本电脑上的数据集。cloud 强制您将所有数据上传到一个地方，才能执行跨源查询。而 MotherDuck 的混合执行方式则更为智能。它会分析您的查询，仅保留每个数据源中的必要数据，并在不同位置之间执行智能联接，从而为您节省时间和数据传输成本。
在底层，MotherDuck 的优化器会将您的查询分解为一个操作的 DAG（有向无环图），估算在本地与远程执行每个节点的成本，并自动处理数据迁移。您只需编写 SQL 语句；MotherDuck 会自动确定最佳执行策略。这种方法从根本上重新定义了cloud 。 我们不再被迫在本地环境的简便性与cloud 之间做出取舍——二者都伴随着数据共享和工作流协调方面的复杂性。借助 MotherDuck，您将兼得两全其美：当您的机器能够胜任时在本地运行，cloud 扩展至cloud ，并全程无缝共享数据。这是一种无服务器解决方案，能够降低cloud ，因为您只需为实际计算的资源付费。
但真正有趣的地方在于：数据共享变得轻而易举。 还记得 DuckDB 的单用户特性曾让协作变得多么痛苦吗？如果一位数据分析师创建了一份出色的分析报告，他们必须导出所有内容并上传到共享存储系统，才能让团队成员访问。而使用 MotherDuck，共享只需点击一个按钮或运行一行代码，即可创建带有适当访问控制的零拷贝快照。无需数据迁移，无需存储冗余，实现即时协作。
请参阅 MotherDuck 的论文，了解更多关于双模/混合查询执行的信息，该论文发表于 创新数据系统研究会议（CIDR）。您还可以观看这场 dbt Coalesce 演讲 。
野鸭
我们已经看到，MotherDuck 不仅能为数据团队大幅减轻工作负担，还能为您的“黄金层”提供强大的分析能力。但理论终究有限。我们希望将 MotherDuck 与cloud 仓库领域的成熟厂商进行对比测试。参考 Metabase发布的《2025年数据堆栈报告》 ，我们发现了一个令人惊讶的事实：即使在分析工作负载中，PostgreSQL 依然是受访企业中最受欢迎的数据库选择，其次是 Snowflake 和 BigQuery。这为我们确定了对比对象。
我们决定将 MotherDuck 与 GoogleCloud 上的托管 PostgreSQLCloud BigQuery 进行性能对比测试，使用 Apache Superset 作为首选的商业智能工具。选择 Superset 有以下几个理由：它是开源的，被广泛采用，并且不仅与 MotherDuck 原生兼容，还兼容其他大多数主流数据库。我们的测试环境由部署在 GoogleCloud Engine 上的 Apache Superset 组成，并连接到三个不同的后端：BigQuery、Cloud 上的 PostgreSQL 以及 MotherDuck。
我们将测试分为两个阶段。首先，我们运行了 TPC-H 基准测试：这是一项标准化的决策支持基准测试，旨在展示 MotherDuck 在受控的理论环境中的表现。随后，我们转向更贴近实际的场景，测试在真实的仪表盘应用场景中，Superset 与 MotherDuck 之间的配合效果与传统数据仓库相比如何。
TPC-H 基准测试
TPC-H 是用于测试分析型数据库性能的标准。它是一个决策支持基准测试，旨在处理海量数据、执行复杂查询，并为不同行业的关键业务问题提供答案。您可以在 官方文档中查阅完整规范。该基准测试包含 22 个查询，模拟了从简单聚合到复杂的多表连接等现实世界中的分析工作负载。
我们分别在 Superset 的 SQL Lab 中对 MotherDuck、BigQuery 和 PostgreSQL 这三个数据库执行了每条查询。我们还直接在 MotherDuck 的图形用户界面（GUI）中测试了这些查询，以消除客户端-服务器延迟；而且坦率地说，任何使用 MotherDuck 的公司，其数据分析师很可能都在 MotherDuck 那种受笔记本电脑界面启发的界面中工作，而非 Superset 的 SQL Lab。此外，MotherDuck 的应用程序可以利用我们之前讨论过的 WebAssembly 架构，我们很想看看这种基于浏览器的执行方式与传统的客户端-服务器模型相比表现如何。 为确保测试公平性，在所有基准测试中均禁用了 Superset 的缓存。
在本次基准测试中，我们采用了 TPC-H 规模因子 10（SF-10），该配置生成了一个 10GB 的数据集。我们选择规模因子 10，是因为 10GB 对于大多数企业的分析工作负载而言是一个切合实际的数据集大小——既足够大，能够体现出有意义的性能差异，又无需部署企业级基础设施。以下是各关键表的数据分布情况：
我们使用 DuckDB 的 TPC-H 扩展在本地生成数据，随后将其无缝上传至 MotherDuck。得益于 MotherDuck 强大的数据加载能力，整个过程仅需几分钟。
以下是 TPC-H SF-10 测试的秒数结果。黄色柱状图显示的是 MotherDuck 应用程序原生界面的测试结果，其余柱状图则代表通过 Superset（SST）SQL Lab 实现的性能：
MotherDuck 在各方面始终能实现一秒以内的响应速度： 通过 Superset 执行的 22 个查询中有 21 个在 1 秒内完成，而直接通过 MotherDuck 应用运行时，所有查询均在 1 秒内完成。BigQuery 表现尚可，但平均 比 MotherDuck 慢约 4 倍 。PostgreSQL 的表现则截然不同，其性能显著较慢，在处理复杂的聚合和连接操作时明显吃力。这在预料之中，因为 PostgreSQL 本质上是为 OLTP 工作负载而非分析处理而设计的，但我们仍将其纳入比较，因为许多公司仍广泛将其用于分析任务。 值得注意的是，如果采用索引、分区或物化视图等适当的优化技术，PostgreSQL 的性能可以大幅提升，但即便如此，它仍将受限于其基于行的架构。这种性能差距恰恰说明了为何会有 MotherDuck 这样的专用 OLAP 系统：当您在庞大的数据集上运行复杂的分析查询时，架构至关重要。
虽然 TPC-H 展示了原始的查询性能，但真正的考验在于这些性能如何转化为商业智能工具中的实际用户体验。
仪表盘性能
我们发现，对于在数据仓库中使用 SQL 进行数据分析的分析师而言，性能表现非常出色，但我们想测试这一改进是否也能体现在仪表盘上——毕竟，这才是业务相关方实际与数据交互的地方。说到底，如果仪表盘加载依然慢得要命，那么再快的 SQL 查询也无济于事。
为了验证这一点，我们使用了来自 Kaggle 获取了一套逼真的电子商务数据集，该数据集包含6750万行数据，总容量达9GB，这正是许多企业在进行月度客户分析时所处理的数据规模。基于这一张数据表，我们构建了一个全面的仪表盘，用于对各系统处理真实业务智能工作负载的能力进行压力测试：
我通过多次测试对仪表盘进行了全面评估，包括应用各种筛选条件、测量加载时间、禁用缓存，以及通过浏览器的开发者工具监控响应时间。经过多次测试循环以确保结果的一致性，以下是仪表盘的性能指标（单位：秒）：
我们的仪表盘加载测试揭示了数据库性能对用户体验的实际影响。MotherDuck 提供了卓越的仪表盘响应速度，平均加载时间仅为 3.35 秒，从而实现了真正的交互式分析，用户可以流畅地探索数据，毫无阻碍。相比之下，BigQuery 加载同一仪表盘需要 8.55 秒。虽然这对于计划性报告尚可接受，但会造成明显的延迟，从而阻碍探索性分析。 PostgreSQL 长达 216 秒（超过 3 分钟）的加载时间，使其完全不适合用于仪表板。MotherDuck 展现的这一性能优势，能够从根本上改变业务用户与数据的交互方式。当仪表板能在几秒内而非几分钟内加载完成时，用户采用率将大幅提升，分析师能够快速迭代洞察，分析能力也将从瓶颈转变为竞争优势。
价格对比
MotherDuck 将存储与 按需付费 计算，专为交互式分析优化。由于它是在单台机器上进行纵向扩展，而非分布在集群中，因此避免了用户最终需要承担的额外开销。数十次查询的会话成本可能仅需 0.05–0.10 美元，而每月运行数千次查询的团队可能仅需花费 20–40 美元。 相比之下，常驻数据库仅为维持运行每月就可能花费 300–500 美元，而cloud 通常按每 TB 扫描量收取 5–10 美元。凭借其纵向扩展设计，MotherDuck 确保了定价的简单、可预测且经济高效。
由于 MotherDuck 收取组织管理费且采用不同的计算定价模式，乍看之下其成本似乎更高。然而，这两个系统采用的定价模式分别更适合不同的使用场景：BigQuery 擅长大规模批处理，而 MotherDuck 则针对交互式分析进行了优化。 在我们的 TPC-H 基准测试中，在 SF-10 上运行 22 次查询，MotherDuck 的费用为 0.03 美元，而 BigQuery 则需 0.60 至 1.00 美元。若将基础设施开销纳入考量，我们的 PostgreSQL 部署仅维持在线运行每天就需 14 欧元，而 MotherDuck 的无服务器架构在交互式分析工作负载方面通常能提供更优的总体拥有成本。
在企业级应用中，成本效益会因使用模式的不同而有所变化。对于海量批处理任务，BigQuery 的性价比更高；而在交互式分析和探索性工作流方面，MotherDuck 则仍具优势。关键要点在于：应根据团队实际处理数据的方式来选择定价模式，而不仅仅关注单价成本。
注：所有定价示例均基于 europe-west4 区域，仅供参考，并非精确数据，因为实际成本在很大程度上取决于具体的用法模式和数据特征。
结论
MotherDuck 标志着我们对分析型数据库认知的根本性转变，它挑战了“必须依靠复杂的分布式系统才能处理高强度数据工作负载”这一传统观念。通过将 DuckDB 的嵌入式理念延伸至cloud，MotherDuck 不仅提供了现代数据团队所需的协作能力，同时保留了使 DuckDB 脱颖而出的卓越性能。
我们的基准测试结果揭示了一个令人信服的事实：MotherDuck 始终以显著优势领先于 BigQuery 和 PostgreSQL，在 10GB 数据集上实现亚秒级的查询性能，其仪表盘加载速度更支持真正交互式的分析。在仪表盘场景中，相较于 BigQuery 的性能优势以及相较于 PostgreSQL 的巨大优势，不仅体现在更快的查询速度上，更在于将分析转变为一种更具交互性和探索性的体验，从而促进数据驱动的决策。
也许最重要的是，MotherDuck 在实现这一性能的同时，还大幅降低了基础设施的复杂性和成本。cloud 需要保持基础设施全天候运行，每月费用高达数百美元，而 MotherDuck 的无服务器模式仅按实际使用量收费，通常能有效降低成本。这种按计算量付费的定价模式与分析师的实际工作方式完美契合：他们在探索性会话中运行多个查询，而非进行孤立且不频繁的请求。
其影响远不止于性能和成本。MotherDuck 的双执行模型和基于浏览器的分析能力预示着，未来本地cloud 与cloud 之间的界限将日益模糊。MotherDuck 不再迫使团队在本地计算的简便性与cloud 之间做出取舍，而是两者兼备，能够智能地将计算任务路由到最合适的处理位置。
在测试过程中，MotherDuck 简单易用的操作和设置给我留下了深刻印象。其双执行模型让我能够无缝地cloud 查询本地和cloud 的数据，而 Superset 与 MotherDuck 之间的连接设置也异常简单。
对于希望从“黄金层”着手实现分析能力现代化的企业而言，MotherDuck 提供了一个极具吸引力的方案：企业级性能、协作式工作流以及成本效益，且完全无需承担传统数据仓库基础设施带来的运营开销。在数据驱动型决策日益决定竞争优势的当今世界，能够以亚秒级速度交互式探索数据的能力，已不再是锦上添花，而是变得至关重要。
准备好亲自体验MotherDuck的表演了吗？ 您可以从 21天免费试用，或使用其免费的10GB套餐 ，用您自己的数据集和工作负载进行测试。如果您想了解MotherDuck是否适合您的特定数据架构，或者需要实施方面的帮助，请联系我们的团队： Artefact团队，我们将很乐意评估您的分析需求，并协助您顺利过渡到更高效、更具成本效益的分析基础设施。
