编译 | Tina
“如果今天重新开始，我不确定还会不会建议18岁的人去学计算机。”
说这话的是数据库领域图灵奖得主Mike Stonebraker（石破天），Ingres与Postgres的核心缔造者，也是数据库发展史上最具影响力的人物之一。在他看来，计算机科学正面临增长乏力的拐点。
这场深度访谈中，Stonebraker直指行业痛点：从Oracle、Google到AWS，他对主流数据库厂商的技术路线提出尖锐批评；同时，他系统剖析了AI时代下数据库角色的不可替代性——尤其当AI从“只读”迈向“读写”，事务、一致性、原子性等经典问题将全面回归。
更值得关注的是他对大模型生成SQL能力的实证评估：在真实数据仓库场景下，准确率仅为0%；即便引入RAG或显式提供JOIN条件，最高仅达35%。而熟练工程师的准确率稳定在90%以上。他明确判断：该技术短期内无法进入生产环境。
Postgres：最好用的起点，不是终点
主持人：Postgres的起源可追溯至Ingres。您是如何进入数据库领域的？
Mike Stonebraker：1971年，我在伯克利任教时，导师Gene Wong建议我们实现Edgar F. Codd刚提出的“关系模型”。当时主流是Codasyl的指针式网络结构和IBM的IMS层次模型，二者均存在严重扩展性与维护性缺陷。Codd的理论简洁合理，我们于1972年启动Ingres项目——这也是我获得终身教职的关键成果。
Ingres成为首个可在Unix上运行的免费数据库，被全球约100所高校采用。但学术成功未转化为商业落地：亚利桑那州立大学用Ingres管理4万名学生数据的项目因缺乏COBOL支持而失败。这促使我们于1980年创立Ingres公司，迁移到VMS系统并提供商业支持。
主持人：Ingres技术优于Oracle，为何输给了后者？
Mike Stonebraker：Larry Ellison是卓越的销售者，但他将“未来功能”包装为“当前能力”出售，本质上是对客户撒谎。例如，Oracle手册用两页篇幅定义“引用完整性”，末尾却标注“尚未实现”。首批客户实质上成了免费测试员。
主持人：从Ingres到Postgres，核心演进是什么？
Mike Stonebraker：源于两个现实需求：一是GIS系统需支持点、线、多边形等自定义类型；二是债券业务要求“30天月制”等非公历日期运算逻辑。Ingres的硬编码类型系统无法满足。Postgres由此设计为可扩展类型系统——用户可定义任意数据类型并保持高性能，这是其最根本的创新。
它还率先支持继承、时间旅行查询（后因实现不佳移除）等特性。虽多数商用场景只需标准类型，但数据库正持续向GIS、金融、时序等垂直领域渗透，扩展能力已成为刚需。
主持人：您主张“One size fits none”（通用数据库实则谁都不适配）。哪些产品仍陷于此误区？
Mike Stonebraker：2004年我们已验证：流处理（StreamBase）、列存数仓（Vertica）、关系型系统三者架构迥异，但各自场景性能均比通用方案高一个数量级。今天依然如此——ClickHouse专精列存，Pinecone优化向量检索，而Postgres既无原生列存，也无多节点支持，在PB级数仓场景已失去竞争力。
但Postgres仍是“最低可行解”：社区庞大、生态成熟、人才易得。只要不涉及百万TPS或PB级数据，它就是最稳妥的起点。
索引一出现，GPU就很难发挥作用
主持人：GPU能否革新数据库性能？
Mike Stonebraker：挑战在于根本性冲突：GPU依赖SIMD（单指令多数据），而索引（如B树）本质是串行内存访问路径——每次查找需逐层遍历指针，天然难以并行。一旦索引是正确解法，GPU便难有优势。
此外，若GPU仅作为CPU协处理器，PCIe总线常成瓶颈。真正发挥效能需重构存储-计算全栈带宽。
主持人：Ingres最早版本是否手写B树？
Mike Stonebraker：全部自研。最难部分是查询优化器——至今仍是数据库系统中最复杂的模块，算法难度极高。
Google是选错了方向，Amazon是选太多方向
主持人：您为何强烈反对MapReduce？
Mike Stonebraker：MapReduce效率极低。2011年我们论文证明：专业分布式数据库可轻松碾压Hadoop。更关键的是，Google同期推广的“最终一致性”（eventual consistency）同样错误——它仅适用于极少数容忍数据短暂不一致的场景（如Amazon可接受24小时发货），却无法保障库存非负等基本业务约束。
Spanner的诞生即宣告放弃：Google最终回归传统事务模型。本质是用数据正确性换取性能，而多数企业无法承受前者损失。
主持人：Amazon的问题在哪？
Mike Stonebraker：他们维护约15种数据库，其中至少12种缺乏足够性能与市场支撑。图数据库等方案，完全可用关系型数据库+上层抽象实现。重复建设不仅增加运维成本，更稀释技术聚焦力。
主持人：您长期坚守学术界而非加入AWS等大厂，原因何在？
Mike Stonebraker：工业界受限于商业规则：论文发表、会议演讲、竞品研究均受约束。我在Informix兼职时发现，两千人规模的官僚体系中个人影响微乎其微。我更适应创业公司节奏——直接面向一线开发者解决问题，快速迭代验证。
把Linux上半部分，换成数据库
主持人：DBOS是什么？
Mike Stonebraker：源于2019年观察：Databricks调度百万级Spark任务时，传统OS调度器失效，最终用Postgres实现调度——因为操作系统本质是大规模数据管理系统。我们提出：将Linux内核之上的所有组件（进程管理、文件系统、调度等）用数据库重构。
该项目由伯克利与斯坦福联合推进，验证了可行性。后续衍生出DBOS公司，聚焦编程语言层创新：提供TypeScript/Java/Go/Python SDK，使应用天然具备事务、持久化、自动Failover等数据库级能力。其核心是工作流（Workflow）模型——每步micro app均为事务性，整个流程可原子执行或彻底回滚。
当前三分之二客户用于agentic AI场景。当AI从“预测Ryan信用分”（只读）升级为“执行转账”（读写），事务与一致性问题必然回归，而这正是DBOS的设计主场。
主持人：用数据库替代OS组件，有何代价？
Mike Stonebraker：实测表明：基于DBMS的文件系统快于Linux原生FS；调度引擎性能持平；且默认获得高可用能力。技术上几乎无明显缺陷。
阻力来自生态惯性——OS与PL领域研究者视其为“地盘入侵”。但变革周期漫长，正如Java普及耗时十年。
在真实数据仓库里，LLM写SQL的准确率是0%
主持人：大模型生成SQL的真实能力如何？
Mike Stonebraker：我们在4个真实生产数据仓库上构建了Beaver基准测试（含匿名化schema与真实查询负载）。结果明确：LLM准确率为0%；加入RAG提升至10%；显式提供FROM子句与JOIN条件后，最高仅35%。而人类工程师稳定在90%以上。
差距源于三大现实鸿沟： 1. **数据不可见**：训练语料不含私有业务数据； 2. **复杂度断层**：公开benchmark（Spider/Bird）SQL平均10–20行，真实查询常超100行； 3. **Schema混乱**：物化视图冗余、列名缩写晦涩（如“jtrm_st_dt”）、本地化概念（如MIT的“J-term”）均超出模型理解边界。
我们的应对策略是： - 将复杂查询拆解为含明确FROM/JOIN的子片段； - 避免跨异构系统（如数仓+CRM）用LLM做JOIN，坚持SQL原生关联； - 推动多源数据统一转为表结构（如将CAD、法规文本映射为SQL表），再以查询优化器思路融合。
第二条主线是agentic AI的读写化演进——它终将回归分布式数据库本质问题：原子性、一致性、隔离性、持久性（ACID）。
计算机科学，可能不再是增长型行业
主持人：对数据库学习者，您的入门建议是？
Mike Stonebraker：推荐《Readings in Database Systems》（红皮书），它收录了八年前及更早的经典论文，仍是最佳知识入口。后续可追踪领域前沿论文。
主持人：若能重选专业，您会建议年轻人学什么？
Mike Stonebraker：“计算机科学未来很可能不再是增长型行业。我不确定今天还会不会建议18岁的人去学计算机。”医疗保健、建筑维修等实操型职业更具稳定性。
对已深造者，建议选择非主流方向——如我们正在推进的Rubicon项目。关键不是追逐热点，而是找到能长期投入的差异化赛道。
最后关于“追随热情”：我并不相信它能自动解决生计问题，但确信——做热爱之事的人，不会在下午5点后才开始生活。
