PostgreSQL之父炮轰半个行业：吐槽Oracle、痛批谷歌，直言计算机行业红利消退
整理自约 20 分钟目录
一、进入数据库领域的契机
二、与Oracle的竞争
三、Postgres的独特之处
四、“一种架构不适合所有人”
五、为什么不同意谷歌和亚马逊的做法
六、为什么选择学术界而不是大型科技公司
七、用数据库替代操作系统中的状态管理
八、数据库的挑战与未来
九、给年轻时的自己的建议
今年是PostgreSQL诞生的30周年。
作为PostgreSQL的创始人，Mike Stonebraker是图灵奖得主，也是数据库领域最具有影响力的学者之一，先后主导打造了Ingres、Postgres等深刻影响整个行业的核心系统，以在数据库底层技术上的开创性贡献闻名于世。
在近期一次访谈中，Stonebraker回顾了自己如何进入数据库领域以及从Ingres到Postgres的演进历程与关键技术突破，并坦诚分享了在数据库架构理念上与谷歌、亚马逊等科技巨头的分歧。面对当下的AI热潮，他也谈到对文本转SQL、智能体AI与数据库未来方向的判断，以及他目前正在推进的DBOS等前沿研究。
以下为这场访谈的中文编译。
一、进入数据库领域的契机
Q：您最初是怎么进入数据库这个领域的？
Stonebraker：毕业后我有幸进入伯克利工作。但我很清楚，继续做博士期间的研究的话，无论是当时还是今天都不会有什么前途。如果能遇到一位懂行的导师引路，会少走很多弯路。Gene Wong至今仍然健在且活跃，他当时收我为徒，提议我们一起做点研究。那是1971年，也就是Ted Cod在《CACM》上发表开创性论文的第二年，Gene提议我们研究数据库方向。当时的竞争方案之一是Codasyl方案，年轻人可能没听说过，它是一种底层网状模型，查询需要沿着指针遍历。另一种是IBM的方案，也就是IMS，这套系统现在依然在使用IMS是层次型数据库，数据按树形结构组织。即使在当时，IBM也意识到树状结构并不够通用，不足以解决很多人的问题。于是他们想出了一个办法，把它改成了有限的网状结构。很明显，这是一个糟糕的办法。Codasyl方案除了底层复杂、难以调试之外，还有一个问题：一旦数据结构（也就是现在所说的schema）发生变化，整套系统基本就要推倒重来，因为它完全绑定在物理存储层。相比之下，Ted Cod的方案则合理得多。
于是Gene说，我们就做个Ingres吧。1972年，我们开始开发Ingres。助理教授大概有五年时间证明自己，要么被解聘，要么获得终身教职。Ingres是我拿到终身教职的门票，而我在1976年如愿以偿。事情就是从这里开始的。
当时很多人会做原型，但有点像学生水平的代码。也就是说，你自己能运行，但给别人就运行不了。所以我们先投入了90%的精力，做出了一个可以运行的版本。然后又投入了90%的精力，让它真正能落地使用。加州大学版本的Ingres最后做得还不错。
之后几年，大约有100所大学开始使用它。因为UNIX系统当时非常流行，这是一个运行在UNIX上的免费数据库系统，所以在学术界非常受欢迎。伯克利也因此迎来了很多前来交流的访客，他们会说：“哇，这东西看起来真不错。你们最大的实际生产应用是什么？”我们往往只能回答，并没有特别大规模的场景。
后来亚利桑那州立大学考虑用Ingres处理他们4万名学生的学籍数据时，我们更加深刻意识到这一点。他们可以接受使用贝尔实验室不被支持的操作系统，也可以接受伯克利这套不被支持的数据库。但当他们意识到Unix系统上没有COBOL程序时，这个项目就彻底失败了。不被支持的操作系统、不被支持的数据库，再加上没有COBOL，注定了我们会被淘汰。很明显，唯一的出路就是创办一家公司。1980年，我们拿到了风险投资，成立了Ingres公司，把Ingres迁移到DEC VAX上。
我们有了正规的公司来维护和支持Ingres，这就是我们商业征程的开始。
二、与Oracle的竞争
Q：我了解到Ingres当时在和Larry Ellison的Oracle产品竞争。我个人感觉Ingres明显比Oracle的产品好，但Oracle那边居然还能竞争下去，他们是怎么做到的？
Stonebraker：Larry Ellison是个了不起的销售。在那个年代，他能把现在能做到的和未来才会有的说得一模一样，所以他基本上是在欺骗顾客。他会把一些根本用不了的东西寄出去，让早期的顾客帮他调试。在我看来，他采取的是一些非常不光彩的商业手段。而欺骗客户，我认为这是毫无职业道德可言的。举个例子，当时有个概念叫“参照完整性”。意思是如果你解雇了一个员工，而他是某个部门的最后一名员工，你是想解散掉这个部门，还是想让它成为一个“幽灵部门”？Ingres公司实现了参照完整性。而Oracle只是写了两页文档，上面写着：这是业界公认的参照完整性定义。然后在文档最底下标注了一行：尚未实现。
Q：我采访过一位曾在Sun Microsystems工作过的人，他们也有类似的看法，认为Larry Ellison有点不靠谱。看来大家对他的评价都差不多。我还在别的地方看到你提到过，Oracle收购MySQL之后，大家都有点慌，于是纷纷转向了Postgres。
Stonebraker：这就是Postgres开始取代MySQL，成为主流开源关系数据库的起点。三、Postgres的独特之处
Q：Ingres有很多技术创新，比当时的主流产品都好，但它最终还是被淘汰了，于是您又开发了Postgres。Ingres有哪些做不到而Postgres做到了的？
Stonebraker：最开始驱动我们的核心原因，是学术版Ingres的初衷：为了支持教授Praveen Varia想要的地理信息系统 (GIS)。要支持GIS系统，就需要点、线、面、线组这类数据类型。但Ingres无法做到这一点。因为Ingres的数据类型都是标准的整数、浮点数、文本和字符串，在这个基础上没有办法高效地支持GIS类型。所以，学术版Ingres在GIS场景下完全失败了。这一点我们一直铭记在心。还有一件事，时间线稍微有点乱，但能说明问题：大概1985年，商业版Ingres推出时，关系数据库刚提出了日期时间标准。于是Ingres商业版按标准公历实现了日期时间功能。当时我还在加州大学当教授，所以也参与了Ingres商业版的开发。后来我接到一个Ingres客户的电话，他说：“你们的日期时间实现错了。”我当时就懵了，我们用的是标准公历，日期相减完全没问题。大月31天、小月30天，二月和闰年也都处理好了，日期计算完全符合预期。但他说：“在我的业务场景里，这不是我想要的。”他说自己在做债券业务，不管每个月实际有多少天，债券每月的利息都是固定的。他有债券买入日和卖出日。他想直接用日期相减，再乘以票面利率，算出应付利息。
当然，他所谓的减法是3月15日减去2月15日等于30天，因为这是他日历的定义。所以他必须先从用户代码中获取两个日期，进行减法运算，然后再把结果写回去，这让他的效率降低了两到三倍。于是他说：“为什么我不能直接重载你们的减法定义，用我自己的规则？”但Ingres里这些逻辑都是硬编码的，根本改不了。
问题就在这里：他需要“债券时间”，就像GIS需要点、线、面一样。所以Postgres从一开始就设计了可扩展类型系统，你可以定义任何需要的数据类型，而且效率很高。Postgres的核心在于它的灵活性。正如你所知，在传统业务数据处理中，大多数人用标准类型就够了。
但关系数据库开始扩展到到各种新领域。抽象数据类型、存储过程这类技术，适用性变得非常广，这就是 Postgres 的最大优势。当时，我们还在Postgres里实现了当时AI领域需要的继承特性，也做了“时间旅行”功能，但实现得太烂，后来就删掉了。
总之，Postgres里有很多很巧妙的设计。
四、“一种架构不适合所有人”
Q：您有一篇论文提出过一个观点：一套数据库系统“适合所有场景”并不理想，实际上没有任何一种架构能适配所有场景。真正需要的是面向特定需求的数据库方案。在您看来，如今市面上有哪些数据库产品依旧在走 “通用型” 的路线？
Stonebraker：2004年我写这篇论文的时候，我们正在做一个学术项目，也就是后来的 Streambase。流处理引擎的架构和关系型数据库完全不同。我们当时初步构思了适用于数据仓库的列存架构，也就是后来Vertica普及的技术，但它和其它数据库架构也截然不同。所以，这里有三种截然不同的实现方式，彼此之间没有任何相似之处。而且这三类专用系统，性能都比通用数据库高出一个数量级。这就足以说明：如果你的业务场景，跑的是一套并非为该场景设计的通用数据库，性能就会直接差一个量级。这个结论放到今天依然成立。比如Clickhouse是列式存储的数据库，Pinecone在文本向量处理上也远优于通用数据库的自定义类型实现。这种情况依旧非常普遍。其实在多种底层架构之上，封装统一的SQL解析器并不难。但Postgres至今没有这么做，它没有实现列存架构，所以在中大型数据仓库场景完全没有竞争力。同时它也不支持多节点分布式架构，而这是大型数仓场景的基本要求。
所以我觉得这句话现在依然适用。如果你遇到数据库问题，想要着手开发，答案就是选择Postgres。它拥有庞大的开发者社区，支持丰富的数据类型扩展，开源免费，而且很容易找到Postgres的技术人员帮你快速上手。对于大多数用户来说，如果你不需要每秒处理一百万笔交易、不需要PB级数据仓库，在低端应用场景下Postgres是最佳选择。但在高端场景下，情况就不同了。
Q：GPU是否为数据库的性能优化带来了新的机会？
Stonebraker：有可能，但我认为最大的挑战是GPU基于SIMD单指令多数据流架构和索引查询的工作机制格格不入。如果索引操作是正确的解决方案，那么GPU可能就不是个好选择。同时，架构设计也必须考虑到这一点，即存储带宽不会成为瓶颈。而GPU大多是CPU的附加组件，那GPU和CPU的总线传输往往会成为性能瓶颈。Q：为什么SIMD架构会让索引失效、性能变差？
Q：您之前提到，Ingres最初版本用到了B树结构。当时所有代码都是纯手写的吗？我印象里那个年代应该没有现成的B树开源库可以调用。
Q：整个开发过程中，最难的部分是什么？
五、为什么不同意谷歌和亚马逊的做法
Q：MapReduce大约在21世纪初问世，在数据领域掀起了轩然大波。大家对它印象深刻，认为谷歌非常专业，简直是划时代的创举。但从我查阅的相关文献以及您当时的观点来看，您似乎非常不认同。为什么如此反对MapReduce？
但这并非谷歌唯一愚蠢之处。谷歌还认为，最终一致性是实现并发控制的正确方案。在同一时期，谷歌高层也提出了这一观点。但事实并非如此。所有数据库专家都说，这个想法不切实际。因为最终一致性只能解决某一类特定类型的问题，而这种场景在实践中非常少见。
Q：他们为什么追求最终一致性？
如果你像亚马逊那样，通常24小时内发货，或许可以超卖。但大多数企业做不到这一点，所以最终一致性就行不通了。我们很久以前就讨论过参照完整性。销售系统中的参照完整性约束是库存大于-1。而最终一致性无法满足这个约束。
最后谷歌的Jeff Dean解决了这个问题。他们开发Spanner时，采用的是传统事务系统。因此，谷歌彻底放弃了最终一致性，也彻底放弃了MapReduce。这是性能与数据完整性之间的权衡。如果你不在乎数据，自然可以接受各种异常结果。
Q：您在其他科技巨头身上也见过类似情况吗？比如亚马逊或Facebook，他们的数据库方案是否也有你非常不认同的地方？
Q：为什么说15套应该精简到3套？
六、为什么选择学术界而不是大型科技公司
Q：您立足学术界，却对整个行业产生了深远的影响。我一直很好奇，相比于加入AWS这类企业、担任顶尖资深工程师，您为什么更偏爱留在学术界，以这种方式输出行业影响力？
七、 用数据库替代操作系统中的状态管理
Q：我觉得DBOS是一个非常有趣的技术模型，您能解释一下DBOS是什么吗？
我们需要开发一个调度器，支撑百万级任务的大规模调度决策。但我们测试了所有操作系统领域开发的调度器，全都无法实现该量级的扩容。所以我们把所有调度数据都放在一个Postgres数据库中，基本上是由一个Postgres应用程序来执行调度。这时我们突然意识到：操作系统的绝大多数核心工作，本质上都是大规模数据管理，而这项工作本就该用数据库技术实现。
既然如此，我们为什么不干脆用数据库替换掉Linux的上层核心模块呢？这就是这个学术项目的要点。21世纪20年代初，我们在伯克利分校和斯坦福大学开展研究，项目取得了巨大成功，方案完全可行。在此过程中，斯坦福大学的研究人员开发了一套JavaScript扩展，提供了可对接这套全新系统架构的编程环境。
如果你在开发一种类似于编程语言的东西，并且运行在一个类似于操作系统（也就是数据库）的东西之上，那么显而易见的做法就是把所有程序状态都放在数据库中。而他们也正是这么做的。因此，我们拥有了一种创新的编程语言模型，一种创新的操作系统模型。紧接着我们萌生了一个想法：能否将这项技术商业化并且成立一个公司？
我们和风险投资人沟通过后，他们都认为：想要取代Linux是天方夜谭。但这套编程语言技术非常出色。我们当时开发了一些JavaScript扩展能力，可以让任何程序都拥有数据库系统的各种优点：数据持久化、事务、故障时自动切换等等。
2023年，我们获得融资，成立了DBOS公司。项目一直叫DBOS，所以公司也沿用了这个名字。当时公司主要聚焦编程语言方面的业务。目前，DBOS已适配TypeScript、Java、Go、Python四种主流编程语言，各语言之间可以无缝衔接运行。它可以在云端运行原生标准程序。开发者完全有充足的理由，将应用架构设计为工作流模式，所以我们决定原生支持完整的工作流系统。DBOS为四种语言提供的工作流能力可将流程中的每一步微操作封装为事务性、可持久化的单元，一旦执行完成，状态永久留存，不会丢失。
如果市场需要，我们可以实现工作流的原子性，这意味着整个工作流要么完成，要么看起来就像从未发生过一样。它具有非常优秀的特性，并且比竞争对手的产品速度更快、使用门槛更低。所以，公司正在该领域进行销售和创新。其核心理念是：将应用的所有状态存入数据库实现持久化，同时保障整体运行的高效性。正如我们之前讨论的，它的商业模式核心是吸引基层开发者。核心思路是：收集一线开发者的需求，快速补齐缺失功能，吸引用户试用。目前我们已经和大量追求最优技术方案的初创公司达成合作，同时也逐步获得大型企业的认可，这是一个很有意思的市场。
我认为目前最关键的是，大约三分之二的客户都在研发智能体AI，即在大语言模型的基础上，搭配各类组件补充多维信息与数据信号。现阶段绝大多数智能体AI都是只读场景，不会更新用户信用数据等信息。但我认为，行业很快会迎来变革，智能体将大规模应用于读写业务场景，这会让AI智能体高度依赖数据库能力，而这正是DBOS 的核心优势。
举个例子，你可以开发两个智能体协作完成转账操作：从我的账户扣款、为你的账户入账，两个操作必须协同确认提交，否则全部回滚。这就是我所说的工作流原子性：要么全部执行成功，要么完全不生效。随着行业对AI读写能力的需求持续攀升，这类技术需求会越来越旺盛。
Q：最初的研究是用数据库彻底替换操作系统的核心内核。这个思路非常新颖，我从没设想过可以用数据库接管操作系统的全部状态管理。这种方案肯定存在一些取舍和弊端吧？
Q：那为什么Linux不整合这套技术，完成自身升级迭代？
Q：您有没有跟Linux用户提过这个问题？他们的普遍反应是什么？
Stonebraker：做学术研究期间，我跟操作系统开发人员提到这一点时，他们会感到非常不安，认为数据库开发人员想抢占他们的地盘。我想编程语言开发人员也是如此，因为数据库会成为实现编程环境运行时的方式。Q：这很有意思，客观而言，如果这套方案更好，未来或许会成为主流。
八、数据库的挑战与未来
Q：我很好奇您如何看待数据库领域目前还没有解决的难题？以及您认为数据库的未来会是什么样子？
Q：您说的文本转SQL，是指人工用自然语言向模型提问吗？
Stonebraker：比如“告诉我所有获得图灵奖的麻省理工学院教授有哪些”，LLM很擅长处理这类问题。目前业界主流的文本转SQL基准测试数据集有Spider和Bird，顶尖的大语言模型在这些测试中表现优异，准确率能达到80%甚至更高。Q：所以还没有达到超人的水平？
原因是什么呢？第一，数据仓库的LLM是在数据堆上训练的，而数据仓库的数据并不在这些训练数据中。有句老话说，如果你之前没见过某份数据几次，就不可能把它复述出来。第二，Spider和Bird测试集中的查询复杂度可能只有10到20行SQL，而实际数据仓库查询可能往往有100行SQL，复杂度高得多。第三，Spider和Bird里的schema很清晰：表名和列名都具有明确含义，而且没有重复，但数据仓库并非如此。人们经常创建物化视图，这意味着存在冗余，列名往往是类似下划线 Z，上标点符号等形式，根本不直观，查找数据变得更加困难。
此外，他们还会遇到一些特殊情况。比如，J-term是麻省理工常见的概念，指一月份为期一个月的学期。虽然并非麻省理工独有，但并不常见，所以它并不在训练语料中。特有的数据、复杂的查询、混乱的schema，这些都会让它无法正常工作。而且据我所知，每一个数据仓库都会有这样的问题。所以我认为这项技术在短期内根本行不通。
那怎么办呢？第一，我们发布自己的基准测试，叫Beaver。它是四个数据仓库经过匿名化和抽象化后的版本。所以，如果你觉得自己真的很擅长把文本转成SQL，就来试试真实的基准测试，而不是虚假的那种。第二，正如我刚才所说：如果没有所有连接条件，也没有FROM子句，那你就完了。更何况，如果不把查询拆解成更简单的部分，你同样没戏。
所以在我看来，你应该向检索系统提供更简单的片段，其中包含 FROM 子句和连接条件。如果你想同时查询两个不同的结构化数据库，比如数据仓库和 CRM 系统，我认为，用LLM来执行结构化数据连接并不是好主意。更好的做法是把它们保留为表，然后用SQL来做连接。我们的观点是：尝试把所有内容都转换成表。
我们之前讨论过智能体AI。一旦系统具备读写能力，它就成了一个分布式数据库问题，你会需要原子性、一致性等这些特性。我认为这是一个非常有意思的方向。
九、给年轻时的自己的建议
Q：如果能回到刚毕业的时候，以您现在的认知会给自己什么建议？
对我来说，更值得问的问题其实是：如果你今天才刚起步，你会选择什么专业？因为我认为计算机科学未来可能不会再是一个增长型行业，我不确定自己会建议18岁的年轻人选择计算机科学专业。我认为医疗保健和建筑行业是比较稳妥的选择，其它行业看起来风险更大。如果你即将获得博士学位，并且正在考虑未来的职业方向，那么我认为选择就比较容易了。先找一份你能找到的最体面的工作，然后找一个愿意帮助你的导师，再选择一个不那么随波逐流的领域，比如我们做的那个叫“Rubicon”的项目，绝对不是那种随波逐流的。所以，选择一个不随大流的方向，然后努力把它做好。我和我妻子都说，去做你热爱的事情，钱的问题总会迎刃而解。其实我一点都不相信这句话，但不得不这样告诉自己的孩子和孙辈。
Q：如果自己都不相信，为什么还要这样告诉他们呢？