Michael Stonebraker 于 1986 年在伯克利推出了 Postgres®。四十年后，他发明的数据库已成为一代 AI 项目的主流选择，而他本人却是这些项目构建方式的最尖锐怀疑者之一。Bruce Momjian 是 PostgreSQL 全球开发小组的联合创始人和核心成员，现就职于 EnterpriseDB（EDB）。在 EnterpriseDB（EDB）即将推出的《AI & Data Horizons》节目系列中，这位图灵奖得主兼 MIT 教授以及 Postgres 社区倡导者都主张，未来属于能够“弯而不折”的系统和不受单一公司控制的社区。
Michael Stonebraker introduced Postgres® at Berkeley in 1986. Forty years later, the database he invented is a leading choice for a generation of AI projects, and he is among the sharpest skeptics of how those projects are being built. Bruce Momjian is cofounder and core team member of the PostgreSQL Global Development Group, and he works at EnterpriseDB (EDB). In upcoming episodes of AI & Data Horizons by EnterpriseDB (EDB), the Turing Award winner and MIT professor and the Postgres community advocate both make the case that the future belongs to systems that bend without breaking, and to communities that no single company controls.
Stonebraker 的第一个展品是文本转 SQL，即业务用户可以用普通英文提问并从数据仓库获得答案的承诺。公开基准测试如 Spider 和 BIRD 报告的准确率超过 80%。他的团队在 MIT 自己的数据仓库——包含 1,400 张学生、教师、建筑和薪酬信息的表——上使用其 SQL 日志中的真实查询进行同样的测试。“我们得到的准确率是零百分比。不是 80，也不是 70，更不是 40——是零，”他表示。
Zero, not 80 Stonebraker’s first exhibit is text-to-SQL, the promise that a business user can ask a question in plain English and get an answer from the warehouse. Public benchmarks such as Spider and BIRD report accuracy above 80 percent. His team tried the same thing on MIT’s own data warehouse—1,400 tables of student, faculty, building, and salary information—using real queries from its SQL log. “We got zero-percent accuracy. Not 80, not 70, not 40—zero,” he said.
加入代理式 AI、检索和提示工程后，准确率提升到十几个百分点。向模型提供每个表和连接词后，准确率达到了三十多个百分点。“仍然还未达到正式使用的水平。”
Adding agentic AI, retrieval, and prompt engineering lifted that level into the teens. Telling the model every table and join term reached the 30s. “Still not ready for prime time.”The reasons are the stuff of every enterprise estate.
原因正是每个企业环境都会面临的问题。没有训练数据，因为该仓库不在公共互联网；数据具有特殊性，例如 MIT 的建筑使用编号而非名称；模式已经腐化为晦涩的表名、列名以及重叠的视图。而且真实查询比基准测试的查询更为困难。他的团队已发布了自己的基准测试——Beaver，并称目前没有人能够突破约 30% 的准确率水平。
There is no training data, because the warehouse is not on the public internet. The data is idiosyncratic: among other things, MIT buildings have numbers, not names. The schema has rotted into cryptic table and column names and overlapping views. And real queries are harder than benchmark ones. His team has published its own benchmark, Beaver, and says nobody has broken out of accuracy levels in the 30-percent range.
Stonebraker 认为，更深层的问题在于架构层面，应该将模型用于其擅长的领域。
Use the model for what it’s good at The deeper problem, Stonebraker argues, is architectural.
大语言模型擅长处理文本，但“它们不擅长的是做结构化数据的连接”，而这正是企业所持有的大部分数据。斯通布雷克（Stonebraker）的团队在与慕尼黑市交通部门合作时发现，要回答一位市民关于人行横道信号灯配时的投诉，就需要把法规、CAD图纸、有轨电车时刻表和学校区域地图结合起来。他说，以语言模型为核心来编排这一切，“贵得离谱”。
Large language models are good with text, but “what they are no good at is doing joins of structured data,” which is most of what an enterprise holds. Working with the city of Munich’s transport department, Stonebraker’s team found that answering a single citizen complaint about crosswalk timing meant combining regulations, CAD drawings, trolley schedules, and school-zone maps. Orchestrating that with a language model at the center was, he said, “ridiculously expensive.”
团队的解决方案是一个名为Rubicon的系统，它只在文本上使用模型，然后把结果转换成表格，其余工作交给表格引擎。这个编排器“看起来像一个查询优化器”。斯通布雷克表示，它的成本只有围绕模型构建的智能体框架的十分之一，而且准确度要高得多。他预计，智能体式AI将从炒作周期的顶峰滑入绝望的低谷，之后才会出现更为平衡的看法。
The team’s answer, a system called Rubicon, uses models only on text, then casts the results into tables and hands the rest to a tabular engine. The orchestrator “looks like a query optimizer.”Stonebraker says it is cheaper by a factor of 10 and considerably more accurate than agent frameworks built around a model. He expects agentic AI to slide from the top of the hype cycle into the valley of despair before a more balanced view emerges.
企业讨厌不确定性：批准了一笔贷款，复核时又推翻，“那就叫官司”。组织还需要防范失控的智能体。他指出，数据库内部的防护栏在很大程度上已经存在：数十年的访问控制、完整的日志，以及能够在事务进行中将其叫停的触发器。他建议，如果调试和版本管理工具能够改进，数据密集型智能体就应当作为用户定义函数存在于数据层内部。
Enterprises hate non-determinism: Approve a loan and reverse it on review, and “that’s called a lawsuit.”Organizations also need protection from rogue agents. The guardrails inside the database, he notes, largely exist already: decades of access control, complete logs, and triggers that can stop a transaction in its tracks. Data-heavy agents, he suggests, belong inside the data layer as user-defined functions, if the tooling to debug and version them improves.
斯通布雷克对前沿领域同样直言不讳。模型已经用尽了互联网上的真实训练数据，而他所知没有任何一家企业会允许模型在其专有数据上训练。他说，AGI“基本上是营销炒作”，是基础模型厂商为了证明其估值合理而制造的。没人拥有它 为什么是Postgres？“Postgres是开源领域的星际答案，”斯通布雷克说。它独一无二的特点是“它不受任何一家公司控制”。EDB、微软、谷歌等各自贡献提交者，没有人来主导。
Stonebraker is equally blunt about the frontier. The models have already used the real training data on the internet, and he knows of no enterprise that will let a model train on its proprietary data. AGI, he said, is “basically marketing hype” from foundation model vendors justifying their valuations. Nobody owns it Why Postgres? “Postgres is the intergalactic answer to open source,” Stonebraker said. Its unique feature is that “it’s not controlled by any one company.”EDB, Microsoft, Google, and others each contribute committers, and nobody steers.
他将这一崛起追溯到甲骨文收购MySQL之时，当时“所有人都说：厂商控制”。对企业而言，这种独立性正是主权的基础：保留对数据系统如何运行、在何处运行的控制权。莫姆吉安从内部描述了同样的结构。Postgres没有办公室、没有资产，也没有法律实体，却能产出“比十亿美元公司更好的软件”。它的预测工具就是社区本身，社区能从中国、俄罗斯和美国及早发现需求。
He dates its rise to Oracle buying MySQL, when “everybody said: vendor control.”For enterprises, that independence is the foundation of sovereignty: retaining control over how and where their data systems operate. Momjian describes the same structure from the inside. Postgres has no office, no assets, and no legal entity, yet it produces “software better than billion-dollar companies.”Its forecasting tool is the community itself, which spots needs early from China, Russia, and the United States.
“我们只需要世界上有一个超级聪明的人，由那个人告诉我们他的想法。”为灵活而设计两位专家都描述了一种设计哲学：宁可牺牲最后几个百分点的速度，也要换取灵活性。斯通布雷克当初把Postgres设计成可扩展的，正因如此，它无需重写就吸收了JSON、全文搜索、GIS，如今又吸收了AI。莫姆吉安补充了上世纪90年代的第二个号召：依靠操作系统，而不是把它吸收进来，这使Postgres天然适合云环境。
“We only need one person in the world to be supersmart, and that person to tell us what they think.”Built to bend Both experts describe a design philosophy that favors flexibility over the last few percent of speed. Stonebraker built Postgres to be extended, and that is why it absorbed JSON, full-text search, GIS, and now AI without a rewrite. Momjian adds a second call from the 1990s: Lean on the operating system rather than absorb it, which made Postgres a natural fit for the cloud.
莫姆吉安抵制那些以僵化为代价换取5%或10%提升的优化，因为一个调校不当的系统可能损失40%。“如果你开着一级方程式赛车去超市，根本没地方放杂货。”这个项目的规划视野很少有厂商能匹敌。“我们在考虑5年后、10年后会有什么影响。”PostgreSQL 19带来什么新版本展示了这种纪律。包括SQL属性图查询以及分区合并与拆分在内的若干预览功能被撤回，因为可靠性优先。
Momjian resists optimizations that buy 5 or 10 percent at the cost of rigidity, since a mistuned system can lose 40 percent. “If you take a Formula One car to the supermarket, there’s no place for the groceries.”The project plans on a horizon few vendors can match. “We’re looking at what would be the impact 5 years from now, 10 years from now.”What PostgreSQL 19 delivers The new release puts that discipline on show. Several previewed features, including SQL property graph queries and partition merging and splitting, were reverted, because reliability comes first.
AI辅助审查正在快速发现问题；2026年8月发布的PostgreSQL 18补丁版本修复了28个CVE。留下来的都是实用功能：针对繁忙表的REPACK CONCURRENTLY、更智能的并行autovacuum，以及逻辑复制的序列同步。来自PostgreSQL主要贡献者和提交者罗伯特·哈斯的“计划建议”（Plan Advice），是社区对多年来一直拒绝的甲骨文式优化器提示的回应。
AI-assisted review is finding problems quickly; the August 2026 patch release for PostgreSQL 18 addressed 28 CVEs. What remains is practical: REPACK CONCURRENTLY for busy tables, smarter parallel autovacuum, and sequence synchronization for logical replication. Plan Advice, from PostgreSQL major contributor and committer Robert Haas, is the community’s answer to Oracle-style optimizer hints it rejected for years.
“有人找到了一种没有这些弊端的方法，”莫姆吉安说。数据库作为AI的记忆。两人在AI编写SQL的速度上存在分歧。莫姆吉安预计智能体会创建数据库并生成大部分代码。斯通布雷克表示，在企业内部，除非数据被记录在案、数据孤岛被打开、政治格局发生变化，否则这不会发生。他们在终点上是一致的。AI需要一个关系型系统来赋予它持久性和记忆，用莫姆吉安的话说，这是“改变游戏规则的东西”。四十年过去了，发明者和守护者押注的是同一个数据库。由EnterpriseDB供稿
“Somebody found a way of doing it that didn’t have the downsides,” Momjian said. The database as AI’s memory The two diverge on how fast AI will write SQL. Momjian expects agents to create databases and generate much of the code. Stonebraker says that will not happen inside the enterprise until data is documented, silos are opened, and the politics change. They agree on the destination. AI needs a relational system to give it permanence and memory, and, in Momjian’s words, that is “a game-changer.”Forty years on, the inventor and the steward are betting on the same database. Contributed by EnterpriseDB