阿里云rds_duckdb：致敬还是抄袭？

非法加冯 · 公众号 · 互联网安全 · 2025-03-06 12:03

主要观点总结

文章主要讨论了阿里云RDS新增的rds_duckdb插件及其与开源项目pg_duckdb的关系，以及对开源项目的态度。指出阿里云在宣传中贬低开源、抬高云服务的行为，并批评其产品粗糙，缺乏真正的创新。同时提到其他云厂商对开源社区的反馈和贡献，强调用户对云厂商的期待。

关键观点总结

关键观点1: 阿里云RDS发布rds_duckdb插件引起争议

文章讨论了阿里云RDS新发布的rds_duckdb插件，该插件与开源项目pg_duckdb有关联。文章指出rds_duckdb的功能相对简单，并未完全借鉴pg_duckdb，但引发关于是否尊重开源的讨论。

关键观点2: 阿里云对开源项目的态度引发质疑

文章批评了阿里云在宣传中贬低开源、抬高云服务的行为，指出其在说明文档等对外宣传中淡化或隐去所使用的第三方开源项目，使得公众认为其是“完全自研”。这种行为被认为是对开源精神的违背。

关键观点3: 其他云厂商对开源社区的反哺与贡献

文章提到其他云厂商对开源社区的反哺和贡献，如AWS RDS推动PG生态的pgvector成为向量数据库扩展的事实标准，开源了多款插件。与此相比，阿里云似乎仍拘泥于“从开源社区和初创公司碗里捞食”的老思路。

关键观点4: 用户对云厂商的期待

文章指出用户对云厂商的期待不仅仅是利用开源，而是能够在创新、优化和深度整合方面做出真正有价值的贡献。用户对云厂商拿出真正有竞争力的产品持期待态度。

正文

看到有人发了一篇《天上的“PostgreSQL” 说地上的 PostgreSQL 都是“小垃圾” 》，文中大肆宣扬阿里云 RDS 新增了一个 rds_duckdb 插件，可以用来做 OLAP 分析，并进一步带出“云 RDS PG 高高在上、PostgreSQL 开源只是‘小垃圾’”的极端观点，令人不适。

我对 DuckDB 及衍生的 pg_duckdb 扩展都很熟悉。其实无论阿里云或其他云厂商在技术层面如何整合开源，只要合法合理合情，我个人都乐见商业与开源互利共赢。但如果有人在宣传层面贬低开源、抬高云服务，甚至暗示开源价值低下，那我确实有必要出来说两句以正视听。

关于 PG DuckDB

DuckDB 是一个高性能的嵌入式 OLAP 分析数据库，我已经关注它很久了。在一年前我写的《 PostgreSQL正在吞噬数据库世界》一文中，着重介绍了 PG 在 OLAP 领域缝合 DuckDB 实现真HTAP的巨大潜力，并成功点燃了全球 PG 社区缝合 DuckDB 的热情。 PG 社区中涌现出好几个将 DuckDB 整合进 PG 的扩展玩家，而这甚至成为了 2024 年数据库领域的一个标志性事件。

在这些整合 PostgreSQL 与 DuckDB 的项目中，由 DuckDB 官方母公司 MotherDuck 联合 PG OLAP 生态初创企业 Hydra 共同开发的 pg_duckdb ，可谓最具潜力。我在其公开发布的第一时间就着手跟进，不仅为 EL 8/9、Debian 12、Ubuntu 22/24 等多种 Linux 发行版的 x86 和 ARM 架构制作并分发了对应的 RPM/DEB 包，还在日常使用和测试中投入了大量精力。

事实上，在我维护的两百多个 PG 扩展插件包里，与 DuckDB 相关的四个扩展是最令我头痛却又最让我兴奋的： pg_duckdb 以及基于它衍生的 pg_mooncake —— 硕大无朋的依赖，复杂的编译过程，多个 libduckdb 的冲突，兼容不同操作系统、不同大版本的 PostgreSQL，难度可想而知。但我相信，这种真正实现 “OLTP + OLAP” 深度融合的探索，十分难得，也值得全力投入。

致敬还是抄袭？

所以，当去年十月阿里云宣布在 RDS 上发布 rds_duckdb 时，我最初的想法是“这总算是好事”。毕竟 pg_duckdb 刚开源两个月，就有云厂商跟进，多少还是在推动产业发展。但很遗憾的是， rds_duckdb 并没有开源，具体实现、细节接口，我们无从得知。不过，从它展现给外部的功能接口上，多少能看出和 pg_duckdb 的相似之处：

比如，早期第一个公开发布的 pg_duckdb 版本，核心接口非常简单，就是 SET pg_duckdb.execution = on; ，然后就可以直接用 DuckDB 引擎来查询 PostgreSQL 表了。而 rds_duckdb 的核心接口就是 SET rds_duckdb.execution = on; ，不过名字从 pg_duckdb 变为 rds_duckdb 。

https://help.aliyun.com/zh/rds/apsaradb-rds-for-postgresql/use-the-rds-duckdb-extension

结合 rds_duckdb 公开发布的时间点（ pg_duckdb 问世后两个月），再加上它的操作方式与行为表现高度相似，可以合理猜想： rds_duckdb 至少在接口与理念上借鉴了 pg_duckdb 。至于代码层面是否有直接引用，由于 rds_duckdb 并未开源，我们也无可考证。

当然， rds_duckdb 自己也“加了点料”，比如支持 PG 12 / 13，多了几个管理 DuckDB 表的小函数（拷贝数据、查看大小等），但技术上并不复杂。要我说，这个功能现在只能算是一个简易原型，远无法跟后续版本的 pg_duckdb 以及基于它构建的 pg_mooncake 相提并论。

较新版本的 pg_duckdb 功能要丰富多了

换句话说，以现在这个“半成品”水平，谈不上什么“剽窃”或“抄袭”。因为 “抄袭”也得抄得像样一点吧？然而，如果说它是“ 致敬 ”，却也让人无从认同。因为无论是在接口文档还是其他地方，我们都看不到任何对 pg_duckdb ，甚至对 duckdb 的署名或感谢。

MIT协议的义务

不过，让人玩味的是，我在阿里云 RDS 文档里搜索翻找了半天，也没看到任何地方留存着 DuckDB 的版权声明或许可证文本。假如 rds_duckdb 并未直接使用 pg_duckdb 的代码，倒还可以解释说“我没用你的东西”，而且知识产权只保护具体的代码而不保护想法，所以不提也就算了。 —— 但你肯定用了 MIT 协议的 duckdb 对吧？ 那么 DuckDB 的 Credit 和 License 在哪里呢？

尽管法律层面最主要的合规点仍是保留版权和许可证文本，但云厂商提供的是在线服务，“交付物”是一个URL和文档，而非 RPM / DEB 软件包，所以用户能接触到的材料就是官方文档。如果在说明文档等对外宣传中，有意无意地淡化或隐去所使用的第三方开源项目，使得公众认为“这是完全自研或完全原创”，那么在舆论与道德层面会被质疑为“抄袭”或“剽窃”。

类似的例子比比皆是，先前“何同学”开源抄袭风波、抖音美摄案、“ 高春辉诉阿里云抄袭IPIP 案，” 以及大家耳熟能详的鹅厂。更别提有大把“国产数据库公司”将开源的 PG 换皮套壳魔改称为“100%纯自研”数据库。都是因为不尊重开源版权、把别人的东西当成“自研”，最终声名狼藉、备受质疑。

在我看来，“从开源社区取经，做成服务售卖”本来不丢人，这在全球范围早就是商业惯例，无可厚非；可如果 “拿了人家的东西，当成自己的发明”就会令人不齿。因为这会留下极其恶劣的印象：企业既没有对外披露应有的来源，也没为社区带来多少贡献，却能坐享其成，大肆盈利。如此一来，开源作者失去了正当的尊重与声望，用户也被蒙在鼓里，这种行为不仅违背了开源精神，更破坏了生态的可持续发展。

对开源的攻讦

说实话，我并不清楚那篇文章的公众号和阿里云之间是否有某种合作关系，也不知道他们为何如此排斥开源。从其近期的文章风格看出，一连串“捧云踩开源”桥段已经不是头一回了：例如《天上的“PostgreSQL” 说地上的 PostgreSQL 都是“小垃圾” 》将开源的 PostgreSQL 视为垃圾；《云原生数据库砸了 K8S云自建数据库的饭碗》说K8S自建数据库是垃圾，以及《开源软件是心怀鬼胎的大骗局 -- 开源软件是人类最好的正能量 --- 一个人的辩论会》，体现出对开源软件的偏见。

这种对开源的偏见与攻讦，实在令人费解。要知道，恰恰是因为开源，一系列核心基础软件才得以百花齐放、加速迭代。 Deepseek 的成功也好，PostgreSQL 越做越大也好，都是脚踏实地站在前人开源巨人的肩膀之上。各大云厂商的“云数据库”大多直接或间接基于开源数据库衍生、优化、深度整合，没了开源，他们的产品根基都将不复存在。

然而时至今日，云厂商从开源社区赚得盆满钵满，却很少进行对等贡献或反馈，导致围绕“ 云厂商白嫖开源 ”这个问题，矛盾正逐渐加剧。但公道自在人心，也并不是所有云厂商都只知道白拿不还：比如 AWS RDS 在这两年投入资源推动 PG 生态的 pgvector 成为向量数据库扩展的事实标准，开源了 log_fdw、pgcollection、pgtle 等多款插件，对社区的反哺社区也是看在眼里的。

再看看阿里云 RDS，似乎仍在拘泥于“从开源社区和初创公司碗里捞食”的老思路，吃相不体面也就罢了，问题在于致敬都致不到精髓，产品做得简陋不堪，难以给用户真正的信心。实际上，对用户来说，不能容忍的不是“云厂商利用开源”，而是“云厂商家大业大，却端出一个半吊子东西敷衍了事” ，搞得像个草台班子，丢的还是阿里云自己的脸。