PostgreSQL 之父 30 周年访谈

由 John Doe 六月 8, 2026

随着 Postgres 今年迎来 30 周年，对 Postgres 项目的创始人 Mike Stonebraker 进行了一次广泛的采访。他讲述了 Postgres 是如何诞生的，他认为 Google 和 Amazon 在数据库方面哪里做得不对，以及他接下来正在开发的内容。

PostgreSQL 之父 30 周年访谈

目录

数据库系统的发展历程与技术演进

1. Ingres 的诞生与商业化

  • 历史背景（1971—1972年）：在 Ted Codd 发表关系型数据库的开创性论文后，Mike Stonebraker 与导师 Gene Wong 决定在伯克利大学开发关系型数据库系统 Ingres（1972 年启动）。

  • 当时的行业竞争格局：

  • CODASYL 方案：一种低级的“网状结构”（Spaghetti network），通过指针执行查询，极难调试。最大的缺陷在于，如果数据库模式（Schema）发生改变，几乎必须抛弃一切重来。

  • IBM 的 IMS 方案：基于树状的层次化数据结构。IBM 自身也意识到树状结构通用性不足，对其进行了打补丁式的修改。

  • 学术版 Ingres 的成功与瓶颈：随着 Unix 系统的兴起，学术版 Ingres 作为 Unix 上的免费数据库在高校中极具人气。但在商业落地时遭遇阻碍（例如，亚利桑那州立大学曾因 Unix 系统缺乏 COBOL 语言支持，无法运行其学生管理系统，被迫放弃 Ingres）。

  • 开启商业化（1980年）：为了提供真正的商业支持，Stonebraker 引入风险投资成立了 Ingres 公司，将系统移植到 DEC 的 VMS 操作系统上。

  • 与 Oracle 的早期竞争：Stonebraker 指出，Oracle 的 Larry Ellison 是一位天才推销员，但在商业行为上存在不诚实的问题。他常常混淆“现在时”与“将来时”，向客户出售尚未实现的功能（例如，在产品手册中写了多页关于“参照完整性”的定义，却在最底部标注“尚未实现”），让初期客户充当白鼠来帮其调试系统。

2. 从 Ingres 演进到 Postgres 的根本原因

  • 硬编码类型系统的局限性：学术版 Ingres 仅支持整数、浮点数、文本字符串等标准数据类型，这导致它在非传统业务场景中完全失败。

  • 地理信息系统（GIS）的失败：Ingres 无法高效支持邻近教授所需的点、线、多边形等 GIS 核心数据类型。

  • 金融债券应用中的瓶颈：1985年前后，Ingres 实现了标准的公历（格里高利历）日期计算。但某金融客户在处理债券利息时，由于业务规定每月利息固定（即“3月15日减去2月15日必须等于30天”），标准的公历减法无法满足需求。客户被迫将数据提取到用户端代码中计算再传回，导致效率下降了两到三倍，且系统无法直接重载减法操作符。

  • Postgres 的核心技术创新：为了解决上述问题，Postgres 被设计为拥有可扩展的类型系统（Extendable Type System）。它支持用户自定抽象数据类型、操作符重载和存储过程。此外，Postgres 早期还支持面向 AI 研究的“继承”特性以及“时间旅行”（后因实现效果不佳被移除）。

现代数据库架构哲学：“一种架构无法满足所有需求”

Mike Stonebraker 坚持其在 2004 年提出的经典观点：“一种架构无法满足所有需求”（One Size Fits None）。

  • 低端市场的通用选择：在数据量和并发量较低的初期阶段，Postgres 是最完美的“最低公约数”选择。它免费、拥有庞大的开发者社区和丰富的扩展类型，且人才易寻。在达到每秒百万级交易（TPS）或数 PB 级数据仓库之前，Postgres 都能完美胜任。

  • 高端市场的专用架构：一旦进入高并发、大数据的极限场景，通用数据库就会失去数量级的性能优势。

  • 列式存储（Column Stores）：专门用于数据仓库（如 Vertica、ClickHouse），其架构与传统的行式存储完全不同，性能可提升一个数量级。Postgres 由于缺乏原生的列存和多节点（Multi-node）支持，在大规模数仓中并不具备竞争力。

  • 向量数据库：专门的向量数据库（如 Pinecone）在处理文本向量和大规模检索时，比在传统数据库中通过用户自定义类型来实现要快得多。

  • 关于 GPU 在数据库中应用的看法：GPU 属于单指令多数据（SIMD）架构，这与数据库的“索引（Indexing）”机制存在天然冲突。例如，在 B-tree 索引查询中，需要多次串行访问内存并跟进指针，这无法被很好地并行化。此外，连接 CPU 与 GPU 的总线带宽往往会成为存储传输的瓶颈。

对科技巨头技术路线的批判

1. 批判 Google：MapReduce 与 最终一致性

Stonebraker 认为，许多技术人员因为盲目崇拜 Google 而跟风，但 Google 在分布式领域的很多早期推崇是错误的：

  • MapReduce / Hadoop 极度低效：在 2011 年的一篇联名论文中，Stonebraker 团队证明了分布式关系型数据库在效率上可以完胜 Hadoop。
  • 最终一致性（Eventual Consistency）的危害：Google 曾极力推崇最终一致性来解决跨地域多活的并发控制，以此牺牲一致性换取性能。Stonebraker 指出，这仅能解决极少数特定场景（如亚马逊允许商品超卖并在24小时内发货），对大多数企业而言，它破坏了数据完整性（Data Integrity）。例如，在销售系统中，“库存不能小于0”是铁律，而在最终一致性下，两地同时卖出最后一个商品会导致库存变为 -1。Google 后来在开发 Spanner 时彻底放弃了最终一致性和 MapReduce，回归了传统的强一致性事务系统。

2. 批判 Amazon (AWS)：支持了过多的数据库系统

  • Amazon 目前在云上支持了约 15 种不同的数据库系统，Stonebraker 认为其中有 12 种是多余的。Amazon 的企业文化倾向于不断叠加产品，但应当淘汰那些在足够大的市场中无法展现出绝对性能优势的系统。
  • 例如图数据库（Graph-based database），在性能表现上它几乎永远不是最佳选择。如果用户需要处理节点和边，完全可以在高效的关系型数据库之上构建一个面向用户的图模型分层（User Interface），而不是单独维护一个低效的图数据库引擎。

操作系统与编程范式的未来：DBOS

Mike Stonebraker 介绍了其始于 2019—2020 年的学术项目，现已商业化为 DBOS（Database Operating System，数据库操作系统）公司：

  • 核心核心概念：操作系统的本质是在大规模管理数据（如进程调度、文件管理）。因此，可以用数据库技术重构操作系统。DBOS 的设想是保留底层的硬件设备驱动，用数据库（如 Postgres）替代 Linux 的上半部分。
  • 技术优势：在数据库之上构建的文件系统比 Linux 原生文件系统更快；调度引擎也极具竞争力；且系统能够天然获得高可用性和故障转移（Failover）能力，几乎没有性能副作用。
  • 商业化转型（DBOS Inc., 2023年成立）：由于风险投资家不相信能直接颠覆 Linux，项目转向了编程语言和云原生工作流市场。DBOS 扩展了 TypeScript、Java、Go、Python 语言，使 leaf-level（基层）程序员编写的代码天然自带数据库的持久化、事务和容错特性。
  • 在 Agentic AI（智能体 AI）中的应用：目前 DBOS 三分之二的客户都在开发 Agentic AI（大模型结合外围组件的系统）。
  • 当前的现状：多数 AI Agent 属于“只读”场景（如预测用户是否为优质客户）。
  • 未来的演进：行业将迅速向“读写”场景演进（例如，两个 Agent 协同执行跨账户转账）。这需要工作流具备原子性（Atomicity），即整个工作流要么全部成功，要么完全回滚。这使得 Agentic AI 变得高度“数据库化”（Databasey），也正是 DBOS 的核心强项。

Text-to-SQL（文本转 SQL）的现实困境

Stonebraker 团队研究了大语言模型（LLM）在现实工业生产环境中的 Text-to-SQL 表现，并得出了颠覆性的结论：

1. 学术榜单 vs 现实工业界

  • 在学术界常用的测试集（如 Spider、Bird）上，顶尖 LLM 的准确率能达到 80%—85%，看起来非常实用。
  • 但在 Stonebraker 团队使用真实工业级数仓建立的基准测试（已开源为 Beaver 基准）中：
  • LLM 的初始准确率为 0%。
  • 引入 RAG（检索增强生成）等各种优化技巧后，准确率仅升至 10%。
  • 如果在 Prompt 中直接给出完整的 FROM 子句（包含所有要访问的表和连接条件），准确率也仅为 35%。
  • 相比之下，熟悉该 Schema 的专业人类程序员在理清文本意图后的准确率可达 90% 以上。

2. LLM 在真实数仓中失败的四大原因

  1. 数据不在训练集（The Pile）中：企业真实的数仓数据和业务模型是外部大模型从未见过的。
  2. 查询复杂度极高：Spider 和 Bird 的 SQL 只有 10—20 行，而现实工业数仓的查询往往长达 100 行。
  3. Schema 混乱且存在冗余：学术数据集的表名和列名具有清晰的助记性（Mnemonic）。现实数仓中充斥着物化视图和大量数据冗余，且列名常常是混乱的代码（如 _Zuppers），毫无逻辑可循。
  4. 包含特异性（Idiosyncratic）业务数据：包含企业特有的非通用概念（例如 MIT 特有的 “J-term” 一月特殊学期），大模型在训练中无法理解其业务含义。

3. Stonebraker 的解决思路

不要试图让 LLM 直接去理解结构化数据并进行 Join。目前他们正在与德国慕尼黑交通部合作，尝试将所有异构数据（SQL 运行数据、CAD 图纸、法律文本等）全部转化为 SQL 表，然后交由传统的查询优化器（Query Optimizer）去执行精确的 Join 操纵。

职业选择与人生建议

  • 坚持学术与初创，拒绝大厂官僚：Stonebraker 坦言自己不适合大企业。在大厂工作意味着必须服从老板、遵守公司规章，这会限制发表论文、参加会议和公开批判竞争产品的自由。同时，大厂内部充满了职场政治（Politicking），他更喜欢在高度自由的初创公司中通过技术直接解决问题。
  • 给 18 岁年轻人的专业选择建议：计算机科学（CS）在未来可能不再是一个高增长的行业。 相比之下，医疗保健（Healthcare）和建筑行业（Building trades）是更稳妥、安全的选择，而 CS 现在的技术风险要大得多。
  • 给博士及研究生的建议：选择最有名望的职位，并寻找一个愿意倾听、能带你入门的优秀导师。在选择研究课题时，不要随大流（Not going with the flow），去寻找那些特立独行、不被当下热捧的方向并坚持做下去。
  • 关于人生的热忱（Passion）：必须要寻找自己真正热爱的事业。许多人仅仅把工作当成赚钱的手段，认为生活只发生在下午5点到次日清晨8点之间，这是很遗憾的。找到热忱所在，即使赚不到大钱，人生也会快乐得多。

参考

Turing Award Winner: Disagreeing with Google, Postgres, Future Problems | Mike Stonebraker

搜索

分类

标签