执行摘要

MotherDuck 通过协作功能将 DuckDB 的分析性能扩展到 cloud，提供比 BigQuery 快 4 倍的性能，并通过无服务器、按使用付费的定价方式比传统的 data 仓库节约成本。在MotherDuck宣布新的欧洲cloud区域后，其性能和诱人的价格给我们留下了深刻印象。MotherDuck 已经可以集成到您的黄金层中，以加快 data 用例的服务速度，同时节约成本。查看性能基准。.

导言

在快速发展的 data 分析领域，一个新的参与者正在挑战 cloud data 仓库的既定秩序。. MotherDuck, 建立在以下基础之上 鸭子数据库‘它拥有快如闪电的分析引擎，可提供企业级性能，并具有现代 data 团队所渴望的简便性和成本效益。但这只 "鸭子 "真的能与老牌巨头相抗衡吗？

我们对 MotherDuck 进行了严格的测试，以检验它是否不负众望。我们的发现挑战了当前分析型 database 的现状，并建议我们从根本上改变基于 cloud 的 data 处理方法。这就是嵌入式 database 如何学会飞行的故事，以及为什么它可能会彻底改变您的 data 堆栈。.

要抓住这种不断变化的顾客，零售商必须迅速做出调整。.

一只正在孵化的鸭子

MotherDuck 将自己描述为 “DuckDB cloud data 仓库，可扩展至 TB 级，用于面向客户的分析和 BI”。要了解这个 cloud data 仓库的特别之处，我们首先需要看看 鸭子数据库, DuckDB 是一个开源 database 系统，在过去几年中悄然改变了 data 堆栈。简单地说，DuckDB 是一个内存 OLAP SQL database 系统。对于那些不懂 database 术语的人，让我们来解释一下它的实际含义：

OLAP 是联机分析处理的缩写。可以把它看作是一个 database，用于快速处理海量 data 数据并回答复杂的业务问题。传统的 database 擅长查找单个记录（如查询客户订单），而 OLAP database 则不同，它可以在数秒内扫描数百万行并执行繁重的计算。它们通过以列而不是行为单位存储 data 来实现这种速度，从而可以快如闪电地分析趋势、计算平均值或汇总整个 data 集的销售额。BigQuery 或 Snowflake 等现代 data 仓库也采用了同样的方法。另一方面，还有 PostgreSQL、SQLite 或 MySQL 等 OLTP（在线事务处理）data 库。这些数据库是为您的应用提供动力的工作母机，每秒可处理成千上万次单独读写，以保证您的应用顺利运行。. 查看有关 OLAP 与 OLTP 的更多信息.

为了了解 DuckDB 的方法到底有多大的革命性，我们需要回过头来看看我们是如何走到这一步的。20 世纪 90 年代中期，随着雅虎和亚马逊等网络巨头的崛起，他们遇到了一堵将重塑整个 data 格局的墙。这些公司被 data（我们后来称之为 “大 data”）淹没，而他们现有的系统根本无法跟上。解决方案是什么？昂贵的单片式基础架构可以应对这种规模。但随着 2000 年代硬件成本的急剧下降，一种新的理念出现了：与其购买更大的机器，为什么不使用大量更小、更便宜的机器呢？这种思想催生了 MapReduce 和 Apache Hadoop 等分布式系统，这些技术旨在将工作负载分散到商品硬件集群中。亚马逊抓住了这一趋势，将这些分布式技术打包成服务，推出了首个大型 cloud 平台--亚马逊网络服务。多年来，这成了默认的玩法：遇到 data 问题时，就将其分布到更多机器上（Fundamentals of Data Engineering, Joe Reis & Matt Housley）。.

但令人着迷的是：当所有人都忙于构建分布式系统时，另一些事情却在后台悄然发生。让分布式计算变得经济实惠的力量，也让单机变得无比强大。如今，你的笔记本电脑已经变得无比强大，拥有更多的内存、更快的处理器和更好的存储空间。DuckDB 背后的开发人员意识到了这个被忽视的机会：如果我们不总是向外扩展，而是更智能地扩展呢？如果我们可以解决许多 data 问题，而完全不需要分布式系统的复杂性呢？

全球部署最多的 database 发动机之一, SQLite 采用了与传统 database 完全不同的方法。PostgreSQL 和 MySQL 作为单独的服务器运行，应用程序通过网络连接到服务器，而 SQLite 则作为轻量级库直接嵌入到应用程序中。没有服务器需要配置，没有网络开销，也没有复杂的设置，只有在应用程序进程中运行的纯本地 database 功能。这种简单性与出色的可靠性和速度相结合，使 SQLite 在从移动应用程序到网络浏览器的所有应用程序中无处不在。.

DuckDB 将同样的嵌入式理念应用于分析工作负载，证明了您并不总是需要一个分布式系统来处理大型 data 数据集。就像 SQLite 彻底改变了本地 data 存储一样，DuckDB 利用本地计算机的原始能力，让分析再次变得简单。安装只需几秒钟，没有任何外部依赖关系，突然之间，你就可以在数千兆字节的 data 上运行复杂的分析查询，而无需启动一个 cloud 实例。.

DuckDB 最吸引人的地方在于它能满足开发人员的需求。需要分析 Python DataFrame 吗？DuckDB 可以直接查询。想要压缩 CSV 文件？没问题。这种无缝集成，再加上其快速的列式引擎，使DuckDB成为分析领域增长最快的database系统之一。性能的大幅提升往往足以让你怀疑当初为什么要使用分布式系统。如果您想深入了解这种方法背后的技术理念，我们强烈推荐您阅读 “使用 DuckDB 进行流程内分析 Data 管理” 由 DuckDB 的联合创建者 Hannes Mühleisen 制作。.

既然你已经了解了什么是 DuckDB，那我们就来谈谈它的局限性。每种技术都有其局限性。DuckDB 只能在一台机器上运行，一次只能接受一个连接。在 data 团队构建服务于整个组织的 cloud 原生解决方案的世界里，这是一个相当大的限制。你无法让多个分析师同时查询同一个 DuckDB 实例，当然也无法像传统 data 仓库那样跨团队共享 data 集。虽然 DuckDB 速度快、操作简单，但它基本上将 data 锁定在一台机器上，一次只能由一个人访问。那么，如何将这个速度惊人但本质上是单用户的 database 变成一个可以为整个组织服务的 cloud data 仓库呢？

学会飞翔的鸭子

这就是 MotherDuck 的用武之地。MotherDuck 是一个无服务器 data 仓库，它在 DuckDB 的原始性能与现代 data 团队的协作需求之间架起了一座桥梁。MotherDuck 创建了他们所谓的 “个性化分析 data 仓库”，为每个用户提供自己的高性能 DuckDB 实例，同时保持在整个组织内共享 data 的能力。以下是该架构的工作原理：

在传统的 cloud data 仓库中，笔记本电脑只是一个哑终端。所有繁重的工作都在远程服务器上进行，你需要按小时付费。但问题是：你的 MacBook 可能比每小时 $20-60 的 data 仓库实例还要快。MotherDuck 尝试通过两种创新方法来利用这种计算能力： 

  • 基于浏览器的分析 将计算直接带给用户。.
  • 双重执行 它能智能地将本地机器的处理能力与 cloud 资源相结合，以比任何一种方法都更快的速度提供结果。.

在深入探讨这两种方法之前，我想说的是，如果将 MotherDuck 的计算能力应用于你的 金层. .对于不熟悉这个术语的人来说，黄金层是经过清理、聚合和丰富的最终业务就绪 data。从本质上讲，经过打磨的 data 集为您的分析、报告和机器学习提供了动力。这些 data 驱动着您最关键的业务决策，因此这里的性能绝对至关重要。每个利益相关者都曾忍受过令人痛苦的缓慢仪表盘，每个 data 团队成员都曾在等待复杂查询完成时盯着旋转的死亡之轮。MotherDuck 能迎刃而解这种困扰。.

浏览器内分析

该解决方案利用 DuckDB 的轻量级和便携式设计，使其能够通过 WebAssembly (Wasm) 直接在浏览器中运行。可以把 Wasm 看作是一种让复杂软件在浏览器中本地运行的技术：无需插件，无需下载，只需在最需要的地方提供计算能力。有了运行在客户端的 DuckDB，您就可以执行复杂的分析查询，而无需像往常一样向服务器发送请求并等待响应。data 处理就在浏览器中进行，消除了网络延迟，完全减少了对基础设施的依赖。您可以通过尝试 浏览器中的 DuckDB.

虽然我们不会在这里深入探讨技术实现，但值得注意的是，DuckDB-Wasm 非常出色。研究详见 本文 它大大优于现有的基于浏览器的解决方案，如 SQLite 的 Wasm 版本或基于 JavaScript 的 database Lovefield。这一巧妙的技术演示标志着我们对分析计算位置的思考方式发生了根本性转变。.

正如 Mehdi Ouazza 在《MotherDuck》一书中解释的那样，MotherDuck 提供了这种由 Wasm 驱动的架构。 本条. .这种方法尤其适用于黄金层分析。您的 data 团队可以使用简洁、业务就绪的 data，而无需担心后端基础架构，本地处理可实现最高速度，而且由于完全消除了网络延迟，您可以获得最快的响应时间。此外，您还可以避免传统 cloud data 仓库对每次查询收取的高额计算成本。这是一个令人信服的提议：更快的分析速度、更低的成本和更简单的架构集于一身。.

 

双重执行

在黄金层中利用 MotherDuck 的另一种方法是通过其双重执行能力，将本地处理能力与 cloud 规模智能地结合起来。MotherDuck 不会强迫你的整个 data 团队共享相同的计算资源，而是为每个用户提供自己的 “小鸭子”：一个独立的、无服务器的计算实例，可根据他们的需求进行扩展。.

在处理分散在不同数据源中的 data 时，双执行的真正威力就会显现出来。想象一下，您需要查询存储在 MotherDuck 中的 data，将其与 S3 中的文件相结合，并与本地笔记本电脑上的 dataset 相结合。传统的 cloud 系统会迫使你在运行跨源查询前将所有内容上传到一个地方。MotherDuck 的混合执行更智能。它会分析你的查询，只保留每个源的必要 data，并执行跨位置的智能连接，为你节省时间和 data 传输成本。.

在引擎盖下，MotherDuck 的优化器会将你的查询分解成一个 DAG（有向无环图）操作，估算本地与远程运行每个节点的成本，并自动处理 data 移动。你只需编写 SQL，MotherDuck 就能找出最佳执行策略。这种方法从根本上重新定义了 cloud 分析。我们不再需要在本地简易性和 cloud 可扩展性之间做出选择，因为二者在 data 共享和工作流协调方面都有各自的复杂性。有了 MotherDuck，您就能两全其美：当您的机器能够处理时在本地运行，需要时扩展到 cloud，并在整个过程中毫不费力地共享。这是一种无服务器解决方案，可降低 cloud 计算成本，因为您只需为实际计算付费。.

但有趣的地方在于：共享 data 变得毫不费力。还记得 DuckDB 的单用户特性给协作带来的痛苦吗？如果 data 的分析师创建了一个令人惊叹的分析，他们必须导出所有内容并上传到共享存储系统，才能让队友访问。有了 MotherDuck，共享只需点击一个按钮或运行一行代码，就能创建一个具有适当访问控制的零拷贝快照。无需移动 data，无需复制存储，只需即时协作。.

从 MotherDuck 的论文中了解有关双重/混合查询执行的更多信息。 创新 Data 系统研究会议（CIDR）. .您还可以观看 dbt 凝聚谈话 由 MotherDuck 联合创始人兼首席执行官 Jordan Tigani 撰写。.

野外的鸭子

我们已经看到 MotherDuck 如何为 data 团队减少大量开销，同时为黄金层提供强大的分析功能。但理论只能到此为止。我们想让 MotherDuck 与 cloud data 仓库领域的老牌企业进行测试。看看 2025 年 Data 堆栈报告 我们发现了一些令人惊讶的现象：在接受调查的公司中，PostgreSQL 仍然是最受欢迎的 database 选择，即使对于分析工作负载也是如此，其次是 Snowflake 和 BigQuery。这为我们提供了比较目标。.

我们决定将 MotherDuck 与托管在 Google Cloud 上的 PostgreSQL 和 BigQuery 进行比较，使用了 阿帕奇超级集 作为我们首选的商业智能工具。Superset之所以有意义有几个原因：它是开源的，被广泛采用，而且与大多数其他主要的 database 兼容。我们的测试环境包括部署在谷歌云 Kubernetes 引擎上的 Apache Superset，并连接到三个不同的后端：BigQuery、云 SQL 上的 PostgreSQL 和 MotherDuck。.

我们的测试分为两个阶段。首先，我们运行了 TPC-H 基准：这是一个标准化的决策支持基准，可以向我们展示 MotherDuck 在可控的理论环境中的表现。然后，我们向现实靠拢，测试 Superset 和 MotherDuck 与传统 data 仓库在真实仪表盘应用场景中的关系。.

TPC-H 基准测试

TPC-H 是测试分析 database 性能的标准。它是一种决策支持基准，旨在检查大量 data、执行复杂查询并为不同行业的关键业务问题提供答案。您可以在 官方文件. .该基准由 22 个查询组成，模拟真实世界的分析工作负载，从简单的聚合到复杂的多表连接。.

我们通过 Superset 的 SQL Lab 对所有三个 database 分别运行了每个查询：MotherDuck、BigQuery 和 PostgreSQL. .我们还直接在 MotherDuck 的图形用户界面上测试了查询，以消除客户端与服务器之间的延迟，而且坦率地说，任何使用 MotherDuck 的公司都可能让他们的 data 分析师在 MotherDuck 受笔记本启发而设计的界面上工作，而不是在 Superset 的 SQL Lab 上工作。此外，MotherDuck 的应用程序可以利用我们之前讨论过的 WebAssembly 架构，我们很想知道这种基于浏览器的执行方式与传统的服务器-客户端模式相比会有怎样的表现。为了确保测试的公平性，Superset 的缓存在所有基准测试中都被禁用。.

在此基准测试中，我们使用了 TPC-H 规模因子 10 (SF-10)，它可生成 10GB 的 dataset。我们之所以选择规模因子 10，是因为 10GB 代表了大多数公司分析工作负载的 dataset 实际大小，足以显示有意义的性能差异，而无需企业级基础设施。以下是 data 在关键表中的分解情况：

我们使用 DuckDB TPC-H 扩展在本地生成 data，然后无缝上传到 MotherDuck。得益于 MotherDuck 的 data 加载功能，整个过程只用了几分钟。.

以下是以秒为单位的 TPC-H SF-10 结果。黄色列显示的是 MotherDuck 应用程序本机用户界面的结果，其他列显示的是通过 Superset (SST) SQL 实验室获得的性能：

MotherDuck 始终如一地全面提供亚秒级性能： 通过超级集进行的 22 次查询中有 21 次在一秒内完成, 在直接通过 MotherDuck 应用程序运行时，所有查询都能在亚秒级完成。BigQuery 显示了可观的性能，但平均 大约比 MotherDuck 慢 4 倍 在整个基准测试套件中都是如此。PostgreSQL 的情况则完全不同，其性能明显较慢，在复杂的聚合和连接方面明显吃力。这是可以预料到的，因为 PostgreSQL 从根本上说是为 OLTP 工作负载而设计的，而不是为分析处理而设计的，但我们还是将其纳入了比较范围，因为它仍然被公司广泛用于分析任务。值得注意的是，如果采用适当的优化技术（如索引、分区或物化视图），PostgreSQL 可以获得更好的性能，但即便如此，PostgreSQL 仍然要与它基于行的架构作斗争。性能上的差距恰恰凸显了像 MotherDuck 这样的专用 OLAP 系统存在的原因：在大量 datasets 上运行复杂的分析查询时，架构非常重要。.

虽然 TPC-H 显示的是原始查询性能，但真正的测试是如何将其转化为商业智能工具中的实际用户体验。.

仪表板性能

我们看到，在 data 仓库中使用 SQL 的 data 分析师的性能非常出色，但我们想测试这种改进是否会转化为仪表盘，因为业务利益相关者实际上是在与 data 进行交互。毕竟，如果您的仪表盘仍然需要很长时间才能加载，那么速度极快的 SQL 查询也就没有多大意义了。.

为了测试这一点，我们使用了来自于 Kaggle 在 9GB 的 data 中包含 6,750 万行，这是许多公司每月进行客户分析的规模。利用这个单一表格，我们建立了一个综合仪表盘，对每个系统处理实际商业智能工作负载的能力进行压力测试：

我在多次运行中对仪表盘进行了广泛测试，应用了各种过滤器，测量了加载时间，禁用了缓存，并通过浏览器的开发工具监控了响应时间。经过多个测试周期以确保结果一致后，以下是以秒为单位的仪表盘性能指标：

我们的仪表盘加载测试揭示了 database 性能对用户体验的实际影响。MotherDuck 提供了卓越的仪表盘响应能力，平均加载时间仅为 3.35 秒，实现了真正的交互式分析，用户可以流畅地探索 data，不会产生任何摩擦。相比之下，BigQuery 加载相同的仪表盘需要 8.55 秒。对于计划报告来说，这仍然是可以接受的，但会造成明显的延迟，从而阻碍探索性分析。PostgreSQL 的加载时间为 216 秒（超过 3 分钟），因此完全不适合用于仪表盘。MotherDuck 的这一性能优势从根本上改变了企业用户与 data 的交互方式。当仪表盘在数秒而不是数分钟内加载完毕时，用户采用率就会激增，分析师就能快速迭代洞察力，分析就会成为一种竞争优势而不是瓶颈。.

价格比较

MotherDuck 将存储与 现收现付 计算，并针对交互式分析进行了优化。由于它在单台机器上进行扩展，而不是分布在集群中，因此避免了用户最终要付费的开销。一次数十次的查询可能只需花费 $0.05-$0.10，而每月运行数千次查询的团队可能只需花费 $20-$40。相比之下，始终在线的 data 数据库仅维持正常运行的费用就高达 $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 在交互式分析和探索性工作流方面保持优势。重要启示：根据团队使用 data 的实际情况选择定价模式，而不仅仅是原始的单位成本。.

注：所有定价示例均基于欧洲-西欧4 地区，应视为示例而非精确定价，因为实际成本在很大程度上取决于具体的使用模式和 data 的特性。.

结论

MotherDuck 代表着我们对分析型 database 的看法发生了根本性的转变，它对需要复杂的分布式系统来处理重要的 data 工作负载这一假设提出了挑战。通过采用 DuckDB 的嵌入式理念并将其扩展到 cloud，MotherDuck 提供了现代 data 团队所需的协作功能，同时保持了 DuckDB 的卓越原始性能。.

我们的基准测试结果令人信服：MotherDuck的性能始终大幅领先于BigQuery和PostgreSQL，在10GB datasets上的查询性能达到亚秒级，仪表盘加载时间可实现真正的交互式分析。与 BigQuery 相比的性能优势，以及在仪表盘场景中与 PostgreSQL 相比的巨大优势，不仅仅在于更快的查询速度，还在于将分析转化为更具互动性和探索性的体验，从而促进 data-driven 决策制定。.

也许最重要的是，MotherDuck 在实现这一性能的同时，还大大降低了基础设施的复杂性和成本。传统的 cloud 设置需要每月花费数百美元的始终在线基础架构，而 MotherDuck 的无服务器模式只按实际使用量收费，往往能降低成本。按计算付费的定价方式完全符合分析师的实际工作方式：在探索会话中运行多个查询，而不是孤立、不频繁的请求。.

其影响不仅限于性能和成本。MotherDuck 的双重执行模式和基于浏览器的分析功能表明，在未来，本地计算和 cloud 计算之间的界限将变得越来越不稳定。MotherDuck 不强迫团队在本地简单性和 cloud 可扩展性之间做出选择，而是两者兼顾，智能地将计算路由到最合理的地方。.

在测试过程中，MotherDuck 的简单易用和设置给我留下了深刻印象。双执行模式让我可以同时在本地和 cloud 中查询 data，而 Superset 和 MotherDuck 之间的连接设置也非常简单。.

对于希望从黄金层开始实现分析能力现代化的企业来说，MotherDuck 提供了一个极具吸引力的主张：企业级性能、协同工作流程和成本效率，而所有这些都不需要传统 data 仓库基础设施的运营开销。在 data-driven 决策越来越多地决定竞争优势的今天，以亚秒级速度交互式探索 data 的能力已不仅仅是 "可有可无"，而是变得必不可少。.

准备好亲自体验 MotherDuck 的表演了吗？ 您可以从 21 天免费试用或使用其免费 10GB 计划 使用自己的 data 设置和工作负载进行测试。如果您想了解 MotherDuck 是否适合您的特定 data 协议栈，或在实施过程中需要帮助，请通过以下方式联系我们的团队 Artefact, 如果您想了解更多信息，请联系我们，我们很乐意评估您的分析需求，并帮助您向更高效、更具成本效益的分析基础设施过渡。.