来源https://letsdatascience.com/news/duckdbs-creator-tells-lds-why-sql-won-5a5e359cDuckDB 的创造者告诉 LDS 为什么 SQL 赢了1 个来源| 2026年8月11日| 由 LDS 团队发布相关性评分7.5快速摘要DuckDB 的创造者 Hannes Muhleisen 告诉 Lets Data Science业界在十年前误诊了 SQL开发人员在 2013 年讨厌的是安装过程、服务器和客户端协议而不是语言本身而那些取代它的 NoSQL 系统又慢慢长回了类似 SQL 的样子却少了四十年的经验积累。他在一次电子邮件采访中认为来自 Snowflake 和 Amazon 的公开工作负载跟踪显示真正需要集群的分析查询只占微不足道的百分比而数据库领域却花了二十年时间为那极小部分需求构建系统他还表示浏览器内的分析应该运行相同的引擎而不是一个玩具版。他还确认 DuckDB 预计今年将有一次未公布的新发布。十年前科技媒体正忙于为 SQL 写讣告。NoSQL 运动如日中天“web scale”是当时的流行语关系型数据库看起来像个老古董。Hannes Muhleisen在荷兰研究机构 CWI 与 Mark Raasveldt 共同创造了 DuckDB认为几乎所有人都误判了病因。“那些讣告是由那些把语言和它所依附的东西搞混了的人写的”Muhleisen 在给 Lets Data Science 的电子邮件采访中说。“2013 年大家讨厌的不是 SELECT。而是安装过程、服务器、与 DBA 的往返沟通、驱动程序以及把你的数据取回来比计算答案慢得多这一事实。这是一个部署问题和协议问题。人们将其诊断为语言问题扔掉了语言却保留了所有实际问题。”他认为那些替代品悄悄地重新发明了它们所抛弃的东西。“替代的 NoSQL 系统逐渐增加了过滤器、连接、聚合并最终用一种声明式的方式来表达所有这些最终又回到了类似 SQL 的样子却少了四十年的经验”他说。“关系抽象的优雅并不受其实现缺陷的影响。业界花了十年的时间才痛苦地学到这一点。”听起来过于明显而不值一提的设计赌注Muhleisen 说DuckDB 的创始理念是数据库领域认为不值一提的数据库应该用起来很愉快。“我们的赌注是用户体验是数据库系统一个合理的设计关注点。这听起来太明显了都不好意思说出口。但这并非共识”他告诉 Lets Data Science。“这个领域无论是学术研究界还是工业实践者都在为基准测试数字和那些可以写进论文里的功能进行优化。是否有人会喜欢使用这个东西则无人问津。”这种优先级来自于观察数据科学家的痛苦。他说团队曾花时间与 R 社区交流“发现满屋子的人都热爱处理数据却讨厌数据库。不是讨厌理论。他们讨厌安装过程、服务器进程、连接字符串以及向系统管理员请求许可的过程。”架构由此需求决定“如果设置必须是一个安装命令那你就不该有一个服务器。”他在一件事上错了。“我以为这会是一个小项目。我们创建一个原型写一篇论文然后就可以回去做更多的研究了。结果 Mark 和我在之后的几年里把无数个晚上和周末都花在了上面。事实证明从内部看SQL 远比从外部看庞大得多。”谁真正需要集群DuckDB 在笔记本电脑上的单个进程中运行这一设计违背了十年的大数据正统观念。当被问及 2026 年的数据科学家在哪些地方仍然需要分布式系统时Muhleisen 指向了公开证据而非个人观点。“这已经不是观点问题了因为跟踪数据是公开的。Snowflake 和 Amazon 都发布了来自他们集群的真实工作负载数据”他说。“典型分析查询很小可以轻松在一台机器内完成而真正需要集群的查询只占不到百分之一。”他并不否认这极小部分需求是真实存在的。他质疑的是业界选择为谁服务。“如果你属于那极小部分你需要分布式系统我不会否认。但请注意谁属于那极小部分。处于那种规模的组织有预算和工程师。他们从来不是需要帮助的那群人。”他说错误是结构性的“包括我曾身处其中的研究界在内的整个社区所犯的错误是花了二十年时间几乎完全为那极小部分需求构建系统。”优化器和协议当被问及数据库领域和数据框dataframe领域的人彼此误解什么时Muhleisen 将责任对半分。他认为数据框用户忽略了查询优化器“在 pandas 中你编写了计划。每个过滤器的位置、每个连接顺序、每个物化的中间结果都是你在不知情的情况下做出的决定。在 SQL 中你陈述结果然后由其他东西付出实际努力来决定如何执行。”数据库领域的失败是它自己的他承认这一点。“我们花了四十年时间让查询变快却几乎没有花时间让答案快速输出。客户端协议是在八十年代为一次获取几行数据设计的并且从未被重新审视”他说。“然后我们还对数据科学家不想使用数据库感到困惑。他们并没有错。”浏览器不是玩具版DuckDB 也通过 WebAssembly 在浏览器内部运行。Muhleisen 认为它所取代的服务器模型是荒谬的。“与数据库交互的每个人都已经拥有一台计算机。它很可能有很多核心和大量内存而他们在查看仪表盘时这台计算机基本上什么也没做”他说。“我们要求组织为他们的每个人在数据中心里租用第二台计算机以便他们可以点击操作。”他对客户端分析的抱负是该领域已不再追求的速度水平。“我们应该谈论的是达到电子游戏帧率的仪表盘你拖动滑块图表就随着你的手动。相反我们已经花了十年时间接受十秒钟的响应时间。”他补充说由于数据从不离开机器“医院或统计机构可以交给某人一个真正的分析工具而无需他们的数据跨越组织边界。”他对此主题的总结性指示是直截了当的“我最想消除的假设是浏览器是放置玩具版的地方。它应该是同一个引擎。”一次未公布的发布以及一个他接受的矛盾当被问及下一步计划时Muhleisen 坦率地表示有所保留。“我最兴奋的事情是我还不能谈论的事情。我们预计今年会推出它。”取而代之的是他提供了一些打破自己创立规则的东西。“我们最近发布了 Quack它为 DuckDB 提供了完整的客户端/服务器操作。能让人理解其意义的例子是一个服务器集群将可观测性事件写入一个具有真正事务性保证的中心 DuckDB 中。这不是任何人在提到进程内分析时所想到的工作负载。”他知道这听起来如何。“你可以认为这是一个矛盾。DuckDB 的存在部分是因为客户端/服务器数据库使用起来很痛苦。”他接受这一点因为另一种选择是教条。“原则上拒绝意味着告诉那些用户我们的自我形象比他们的工作更重要。”这又把他带回到第一个回答。“把用户放在第一位不是你采纳一次然后就捍卫的口号。它会不断地让你付出代价包括我们自己引以为傲的架构纯洁性。”关键要点DuckDB 的创造者 Hannes Muhleisen 告诉 Lets Data Science业界将 SQL 误诊为一个语言问题而真正的痛点在于安装过程、服务器和一个在八十年代设计的客户端协议。他引用了 Snowflake 和 Amazon 的公开工作负载跟踪典型的分析查询适合在一台机器上运行只有极少百分比的查询真正需要集群然而该领域却为那极小部分构建了二十年。他确认预计今年将有一次未公布的发布并为推出 Quack完整的客户端/服务器 DuckDB辩护称这是在为用户需求而非架构纯洁性做选择。