每个月，X 上都会流传一个让人后背发凉的故事：某个开发者让 AI Agent 帮忙搭个东西，Agent 反手冲进数据库，把生产环境的文件删了个精光。Replit 出过这事，其他平台也出过。人们一边惊呼“AI 太危险了”，一边继续把生产库的密码交给 Agent。
但在数据库圈子里，这件事的荒谬之处在于，这些灾难本可以避免，因为防止人类干蠢事的机制，几十年前就已经存在了。
卡内基梅隆大学的 Andy Pavlo 教授，是数据库领域最接近“神”的存在之一，他的课程教会了整整一代工程师，也顺带喂饱了今天的 AI 模型。最近他以数据库研究副总裁的身份加入一家实时分析数据库公司 ClickHouse，核心产品是一个列式 OLAP（联机分析处理）数据库管理系统。
日前，Andy Pavlo 在 The MAD Podcast 播客中，与主持人 Matt Turck 一起，讲清了 Agent 时代数据库正在发生的四重变化：从向量数据库的退潮，到 Agent 删库的护栏问题，再到 AI 能否从零构建数据库、自动驾驶数据库的十年历程。本文基于该播客视频整理，经 InfoQ 编辑。
太长不看版
Q：Agent 删库这事为什么老发生？
A：Agent 删库不是新问题，是旧问题被重新暴露，权限和管控手段几十年前就有，只是大家急着让 Agent“能干活”，忘了先问“它干错了怎么办”。
Q：该怎么给 Agent 加护栏？
A：把它当成一个刚会走路的小孩，你不会不装楼梯护栏、不封插座就让他满屋跑。给 Agent 设好权限，让它根本进不去生产库、删不掉不该删的表，再配合分支造沙箱环境。别想着坐在旁边一个个点“批准”，那样你没法同时给几百个 Agent 当保姆。
Q：向量数据库还值得投资吗？
A：护城河并不深，说到底它只是一个索引。一年内所有数据库厂商都有了向量能力，从差异化优势变成了入场门槛。但不会消失，会朝两个方向演化：要么变成 Postgres 那样的通用系统，要么像 Elasticsearch 一样做独立附加组件。
Q：text-to-SQL 现在靠谱了吗？
A：现成方案准确率大概 60%。一家大银行花了几年时间、投入数百万美元构建语义层和上下文层，才把准确率提到 99.5%。所以可行，但前提是你得像那家银行一样有钱有闲。普通人下载个现成工具，达不到那个水平。
Q：AI 真能从零构建一个数据库吗？
A：能。CMU 的数据库课程项目，一年前 Agent 还做不全，Opus 4 发布后闸门打开，几乎不需要提示就能全部做完。而且超过 60% 的开源数据库已经出现了 Agent 参与的 commit，AI 已经在构建了。
Q：LLM 调数据库参数，比传统自动调优强在哪？
A：传统模型要训练几个小时甚至更久，还得有足够训练数据，才能产出“纯净最优”配置。LLM 15 分钟就能给出“足够好”的结果，做到大概 85% 的程度。而“足够好”对绝大多数人来说就是真的好，毕竟很多人跑的就是亚马逊开箱即用配置，那玩意儿简直糟透了。
Q：数据库市场是不是停滞了？
A：如果拿 AI 当参照系，所有东西都像停滞。但关系模型不会消失，就像你不会发明新算术取代 1+1=2。SQL 可能变成新的汇编语言，但底层逻辑不变。真正重要的往往是数据库之上的那层脚手架：UI、开发者体验、数据摄入、互操作性，Snowflake 成功的一部分原因就是把这些周边做得特别好。
Agent 频频删库，如何防护？
Matt：两年前，数据库和 AI 的话题就出现过，那时候是向量数据库的时代，整个理念是你需要做 RAG，结合聊天机器人搜索。显然，我们现在处于 Agent 时代。这有什么不同？
Andy：从“AI 与数据库”成为时代热词的角度看，大概两年前确实是 RAG 和向量数据库冒出来的时候。但向量数据库本身，很多其实从 2016 年就存在了。只是到了现在，它们的用途才变得显而易见，你可以用它们来增强和改进 Agent 做的事情。
向量数据库市场很有意思，它们很早就进入这个领域，真正在推动的是一个理念：你希望对向量或 embedding 做近似相似度搜索，而不是传统数据库系统做的精确搜索。当你处理自然语言时，这一点尤其有用，因为你要找的东西，语义上可能没法精确定义。比如“给我找出纽约市所有关于某种活动的专辑”，你很难精确描述那到底是什么。
所以当聊天机器人爆发、所有人都意识到这项技术存在的时候，向量数据库正好站在了正确的位置、正确的时间。但护城河，并没有那么大。因为说到底，它只是一个索引。一年之内，几乎每一家数据库厂商都有了自家的向量索引，现在这已经成了标配。
这不代表向量数据库在某些事情上不能比传统数据系统做得更好，只是现在大家都有了那个基础功能。所以你仍然会用向量搜索来增强和改进聊天机器人、Agent，只是你不再需要一个专门的、只能做这件事的数据库了。
Matt：大概一年前，Databricks 收购 Neon 的时候，有一个数据：Agent 创建 Neon 数据库的比例从 30% 涨到了 80%。什么叫“Agent 创建一个数据库”？为什么 Agent 需要一个数据库？
Andy：我觉得那个数据说的主要是 Agent 创建的分支（branching），分支就是当你有一个数据库，你想给它做一个写时复制的快照，让它在逻辑上看起来像两个独立的数据库。
为什么要这么做？你有一个跑着业务和应用的 production 数据库，也就是你的 system of record，所有的变更都往里面写。但你又想让一个人类开发者或者一个 Agent 去尝试新东西、改应用，而且希望他们是在真实的数据库上操作。传统做法是复制一份数据库，或者用一个更小的样本版本，因为完整复制太贵了。所以你搞一个 staging 或者 development 数据库，改完之后再往 production 上应用，然后祈祷放大到真实规模时一切正常。
分支让你做的，是对真实数据库做一个快照，你所有的改动都进快照，不影响 production。 等你对 schema 或者应用代码改动满意了，再把它上线到 production，很多时候这些分支是 GitHub Actions 里跑 PR、跑测试时创建的。
Matt：那再往更简单的层面说，Agent 需要创建一个数据库，是因为 Agent 会对世界采取行动。如果你让一个 Agent 去创建一个应用，应用归根结底还是需要一个数据库。
Andy：你给 Coding Agent 一个 prompt，说“这个应用要做这个那个”，它就会立刻创建一个数据库。大多数被创建的分支，或者说新数据库，都是为了开发这件事。不过确实，Agent 现在确实能创建数据库了。换个说法，你也能让它们删数据库。人们经常因此惹上麻烦，因为它在做不该做的事。
Matt：每年都会出一次很有意思的事故，还在 X 上被传得挺广。SaaStr 创始人 Jason Lemkin 想用 Replit 搭点东西，结果 Replit 的 Agent 冲进数据库，删了一大堆文件。后来 Replit 也做了相应的调整。显然，现在这一切都还是蛮荒西部（译者注：规则不完善、约束不足、大家随意尝试、容易出乱子的状态）。
Andy：我们其实早就有能力防止人们干那些不该干的蠢事，控制手段一直存在。只是每个人都想重新发明轮子，然后人们只能用惨痛的方式，去重新学会过去早就做过的事。
Matt：在 Agent 的世界里，数据库到底需要有哪些目前还不存在的东西？
Andy：护栏。你可以这么想，你家里新添了一个蹒跚学步的小孩，你不可能不装护栏，就让他往楼梯底下摔，或者把手指头捅进插座里。对待这些 Agent 也是同一个道理，你得把它们当成幼儿来看。当然它们比幼儿要精密一些，但你不能让它们在生产库上撒野、想干嘛干嘛。你当然可以坐在旁边盯着，一个劲儿地“批准、批准、批准”，就像在 Claude Code 里那样。但问题是，这样一来你就没法扩展了。
所以正确的做法是设置好权限和管控，让它们根本进不去生产库、删不掉不该删的表。反过来也一样，它们不该读的东西，你也不该让它们随便读。只要你把护栏设对了，再配合分支或者别的什么手段，给它们造出沙箱环境，那些灾难就能避免。你现在每个月都能看到一条新闻，某某因为 Agent 删了不该删的东西，把生产库搞没了。其实只要护栏到位，这些事本可以不会发生。
Matt：那这些护栏，跟现在给人类用的是同一套吗？
Andy：这就是个更大的问题了，Agent 现在的行为方式，除了能 7×24 小时连轴转之外，跟人类到底有没有本质区别？我还没看到任何证据表明，它们开发软件的方式、或者产生不准确数据的方式，跟人类有什么不同。归根结底，数据系统暴露出来的能力就那么多，你能碰到的就是那套 API。所以只要你能约束住人类对这些 API 的使用，你就能用同样的方式约束 Agent。
护栏能做到多精细，取决于你在用什么产品。我很喜欢开源数据库，但那些企业级的商业传统数据库，它们早就替你把这件事做完了，过去几十年为人类用户积累了大量保护机制，现在只要把这些机制同样暴露给 Agent 就行了。
数据库流量的四个时代
Matt：你刚才提到了量和扩展性，如果未来有几十亿个 Agent 在采取行动、跟数据库打交道，这会不会改变一切？
Andy：现在下结论还太早。量当然是个问题，因为 Agent 是 7×24 小时在跑的，人做不到这一点，但数据库历史上其实已经见过类似的量级跃迁了。
第一个时代，大概是 70 到 80 年代，数据库本身刚刚诞生。你终于可以把信息放进去、跑事务、为组织存储东西了，在那之前，一切都还是纸笔。那个时代数据库流量确实有一个明显的增长，但主要是人在工作场景里跟数据库交互，因为没人会回家还去用数据库，80 年代家里也不一定有一台电脑。
第二个时代，是 90 年代到 2000 年代初，互联网来了。每个人都能通过网站、通过家里的网络跟数据库交互，流量又出现了一次跃升。
第三个时代，是手机。现在每个人在任何时刻都有各种 app 在跑，可以跟网站交互，从数据库里读数据、写数据。
现在，Agent 就是这个故事的下一个章节，每个人不仅有一部手机，还可能有几百个 Agent 在替他行动，去读、去写数据库里的数据。说到底，你的应用背后永远是一个数据库，应用要读写数据，最终都会落到数据库上。
但我不觉得我们已经到了那一步，因为显然不是每个人现在都有几百个 Agent 在 7×24 小时地跑。有意思的地方在于：当一个人用手机、笔记本、网站或应用跟数据库交互时，他其实只在自己醒着的时候做这件事，而且一次只能做一件事。我没法一手拿手机、一手拿笔记本同时操作，人的能力是有限的。但你可以想象一个世界，这些 Agent 就是 7×24 小时一直在跑，像人一样去交互，那量级的增长会相当显著。
而且，你可能会问，Agent 跟现在的 IoT 设备、手机有什么本质区别？IoT 设备只是不停地流式插入测量数据，手机 app 通常是在读数据。但你可以想象 Agent 做的是更复杂的操作，是读和写的组合，这让流量变得更有意思。所以我认为，未来打到数据库上的查询量可能会出现 10 到 100 倍的增长。
我还不确定的一点是：Agent 交互的复杂程度，到底是比人现在能做的更复杂，还是更简单？ 有人说，Agent 生成的查询、生成的 SQL 其实更浅，因为它可能只是一次读一两张表，看看里面有什么；而人用 dashboard 或者 BI 工具比如 Tableau、MicroStrategy 的时候，可能会做跨多张表的非常复杂的 join。我目前还不知道 Agent 到底到了那个水平，还是只是用更简单的方式去读数据库里的数据。
Agent 会改变一切吗？我认为会。至少在量上，现在肯定是，而且还会继续增长。当然，Agent 跑起来之后还会生成自己的遥测数据，你得把这些也存下来、理解它，这是另一个挑战。但至于它们的行为模式到底有多不一样，这还有待观察。
Matt：现在有一个概念叫 Agent Memory，看起来正在成为一个战场。一边是文件系统，另一边是数据库。你怎么看？
Andy：文件系统就是一个数据库。说到底问题是：你想提供给 Agent 的输入或上下文，形式到底是什么？据我所知，现在全都是人类可读的文本。那么这段人类可读的文本，究竟是来自你目录里的一堆 JSON 文件，还是从某个数据库系统里抽取出来、再转换成正确的输入形式，其实并不重要。
当你使用一个数据系统时，显然能获得一些优势和安全保证，它能保护数据。SQLite 在这方面就非常有名，你为什么要用一个文件系统，自己去操心写入是否正确、是否安全、能不能做多次修改再提交，而不是直接用 SQLite 把它做对呢？所以归根结底，所有人都应该把所有东西放进数据库系统里。甚至有些文件系统，比如 WinFS，在底层其实就是一个数据库系统。
Matt：多 Agent、子 Agent、Agent 集群的世界，是不是更需要数据库？
Andy：如果你需要在多台机器或多个 Agent 实例之间共享状态，不管它们是不是跑在同一台机器上，数据库管理系统提供的正是这种能力：你可以有多个读者去读取共享状态。我还没见过哪种场景，Agent 在查询记忆时会把过滤条件下推到数据库里，通常这些都是作为上下文提供的。这又回到 RAG 或向量数据库那套东西：你根据已经查到的内容，去对照你的记忆，来提供上下文。
所以从我的理解来看，输入给上下文的 API 就是人类可读的文本，它来自文件系统还是数据库系统都无所谓。但数据系统能提供一些文件系统给不了的保证和便利，跨多个 Agent 的共享状态就是其中之一。
AI 推荐数据库：新型 SEO
Matt：那你有没有观察到 Agent 世界正在收敛到某种特定类型的数据库？
Andy：无论是把它用作记忆，还是让 Agent 在构建应用时去选择某一个数据系统而不是另一个，也许更多是后者。模型是吃人们写的东西训练出来的，所以如果我现在说我要构建一个新应用，大概率它推荐的会是 Postgres，因为这就是预训练语料里的东西。
已经有两家数据库公司来问我，怎么才能让自己的数据库被 Agent 优先推荐，而不是 Postgres。我当时就说，第一，这不是我干的活；第二，去找那些做模型的人，他们显然对这件事有影响力。这本质上就是 SEO，你怎么让 Agent 学会“我该用 X 数据库而不是 Postgres”。
Matt：我怀疑逻辑是这样的：你的文章被搜索引擎高度索引，那么向搜索引擎“推销”你，就成了一种向模型“推销”你的方式。
Andy：我不是想炫耀，但我确实遇到一个问题：当我问关于数据库的问题时，它会把我自己的内容引用回给我自己，因为我所有的课程材料都在网上。但问题是，这其实并不好。比如我在教数据库课的时候，我会说，我想了解那些做某种索引的数据系统之类的。然后我现在必须得说：我已经知道哪些系统做这件事了，给我看看那些不这么做的。然后我还得加一句：别引用任何我写的东西。
还有一个麻烦是，我们所有的课程材料都是开源的，任何人都能拿去用。所以模型会说：行吧，那我不引用卡内基梅隆大学了，我引用另一所大学。但那其实是我的幻灯片被另一门课重新使用了。所以我得变得非常具体，才能说清楚哪些东西不要返回给我。
关于 OLTP，我有一阵子没试过了，但通常它会吐回来一句“你应该用 Postgres”，除非你说得非常具体，比如“我要跑在嵌入式设备上”，那它才会说用 DuckDB 或者 SQLite 之类的；或者你说“我只关心键值”，它可能会回来说用 RocksDB。然后它可能会接着推荐：你想要托管版本还是自己部署？
对于 OLAP，我倒是很好奇会不会有某种排名。它肯定会先给一个答案，然后你可能得进一步细化，说“我的工作负载长这样，我的数据长这样”，然后它才能给出更细致的回答。我大概有一年没试过了，但我以前确实见过它说：你有钱吗？有。那你可以用 Snowflake 或者 Databricks；没钱，那你可以用 DuckDB；你想本地部署吗？那你可以用 ClickHouse，诸如此类。
Matt：这里可能还涉及一个上下文层、本体论（ontology）的概念，它似乎正在把大家推向图数据库。这些到底有没有道理？
Andy：我不认为你需要图数据库。我还没见过任何基准测试能证明原生图数据库能胜过关系型数据库系统，前提是那些关系系统在 SQL 或 API 里具备了正确的构造，让你可以在服务端完成图遍历，而不是来回往返。上下文层该用什么，取决于你的需求，你有多少个 Agent、是否在多个 Agent 之间共享状态。对很多这类场景来说，Postgres 往往应该是首选，尤其是做 OLTP 的时候。如果你做的是分析型负载，那就是另一回事了。
MCP 与 Text-to-SQL 的突破
Matt：过去一年左右，好像每家数据库厂商都在自己的产品里加了 MCP server。你怎么看这件事？一两年前有过一波 text-to-SQL 的热潮，所有人都想让 LLM 直接在数据库上跑，尤其是做分析场景，但那一波好像没成。我们现在到了那个临界点了吗？
Andy：Text-to-SQL，也就是自然语言转 SQL，这件事人们从 70 年代就开始尝试了。每隔一段时间，自然语言处理领域就会出现某种突破，大家就说“这下终于能成了”，但一直没成，直到 LLM 出现。不过我对学术界和各种框架的研究论文一直持怀疑态度，因为它们的 benchmark 往往就是 Spider 那几个众所周知的测试集，而这些模型根本就是在这些 benchmark 上训练过的，那它当然能背出正确答案。
我昨天刚跟一家非常大的银行的人聊过，他们说现在已经有了 text-to-SQL 接口。最初的实现用的是市面上的现成方案，后来他们在内部做了一些改进，但准确率大概只有 60%，这跟我之前在其他报告里看到的数字差不多。但他们说，通过构建更丰富的语义层和上下文层，花了几年时间、投入了数百万美元，现在已经把准确率提升到 99.5%，这简直离谱。
我认为如果你愿意投入时间去构建正确的语义层和所需的上下文信息，让 Agent 有足够的信息从你提出的问题推导出正确的 SQL 查询，这在今天已经是可行的了。但再说一遍，那是一家钱多到花不完的大银行，他们才做到了这一点。如果你现在随便下载一个现成的工具，一个普通人会发现这些工具根本达不到那种准确率水平。
至于 MCP，我理解他们为什么做这个。它出自 Anthropic，然后所有人很快就把它采纳为标准了。每隔一段时间 Hacker News 上就会有人发帖说“MCP 已死”之类的，但我不觉得它会消失。它本质上就是一个 REST 接口，一种标准化的方式，用来描述 Agent 想从你的数据系统里请求什么。接收 MCP 请求的数据系统，它的工作就是把请求转换成正确的 API 调用去取数据。对数据库系统来说，就是生成 SQL 查询去拿数据。但通常它只是对你传入的内容做严格翻译，而不是去试图推导 MCP 请求的语义含义，因为 MCP 请求本身必须定义得足够明确。
我对 MCP 没有任何意见，因为它让你更多地使用数据，而不是搞一些自研的土办法。它能改进吗？我觉得它效率不高，因为你是通过网络发送人类可读的文本去检索数据。用二进制协议显然有更好的做法，但归根结底，它够用了，而且看起来已经成了所有人都在用的标准。
Matt：那安全层是不是应该由你之前提到的那个层面来负责？
Andy：对。但这跟请求来自传统应用客户端用 JDBC 或 ODBC 发来的 SQL 没什么区别，不管是走这些数据系统的网络协议或终端，还是走 MCP 的 REST 请求，本质上都一样：好，我收到了这个请求，我需要搞清楚是谁在请求、想做什么、以及应不应该允许。所以，我们之前聊的那些防护措施，不管是 SQL 进来的还是 MCP 进来的，是同一套东西。
Matt：那我们把讨论翻个面，从“数据库作为 Agent 的记忆层或执行层”，转到“AI 能为数据库做什么”。显然我们活在一个 AI 几乎能写任何代码的世界里。这对数据库也成立吗？
Andy：成立。我在卡内基梅隆大学（CMU）教一门关于数据库系统的课程。我们的项目是这样的：给你一个数据库系统的脚手架，然后你得去实现索引、查询引擎之类的部分。一年前，Agent 还只能做一部分，做不全。后来 Anthropic 发了 Opus 4，闸门一下就打开了，Agent 基本上能把我们所有的作业都做出来，而且几乎不需要什么提示，因为训练数据太多了。
我们所有的项目都是开源的，有海量的训练数据供它学习怎么实现这些东西。我认为现在 Agent 基本上能实现任何你想构建的数据库系统，当然，你得用正确的方式去提示它，得手把手带着它，确保它先产出正确的设计，再基于你要的设计去生成实现。
Matt：但我作为风险投资人构建数据库的经验是，这是一段长达十年的痛苦旅程，头三年几乎什么都没发生，然后世界上最聪明的一批人聚在一起，去解决每一个当时看起来都不可逾越的问题。现在你说它能构建整个东西？
Andy：数据系统领域有句老话：构建一个数据系统要花十年，但前 90% 你三年就能做完，剩下那 10% 要再花七年。所以我认为，只要有足够的 token，再加上足够的指导，人们可以 Vibe Coding 出整个数据库系统。
我有一个自己特别喜欢的副业项目，叫 database of databases，网址是 dbdb.io。我们做的一件事，就是把我知道的每一个数据系统都记录在案。对那些开源的，我们每天晚上都会把 GitHub 上最新的 commit 全部拉下来，然后追踪哪些 commit 实际上是被 Claude 或者 Codex 这类工具参与“署名”的。很多人会把这个功能关掉，你没法百分之百确定某段代码到底是不是 AI 生成的，但大多数人不会去关它。而到现在，我认为超过 60% 的开源数据库系统，已经出现了来自 Agent 的 commit。
自动驾驶数据库之路
Matt：写代码这件事能自动化，那么运行数据库本身呢？你十年前就在做“自动驾驶数据库”这个概念了，那是个大项目。能不能带我们走一遍这段旅程，当年不可能、而今天变成可能的东西，到底是什么？
Andy：我到卡内基梅隆大学之后做的第一件事，就是头几年到处去走访企业，看他们在数据库上到底遇到什么麻烦。结果我发现，反复出现的主题惊人地一致：运行、维护、优化这些系统，本身就是一个巨大的挣扎。从 1970 年代关系模型被发明出来开始，人们就一直在尝试做自动调优：索引、分区键、分片键、各种调优旋钮，全都试过。微软研究院在 2000 年代初还搞过一个叫 Auto Admin 的项目，做了一堆工具来自动管理和优化数据系统。
为什么这件事这么难？因为一个数据库的配置组合有成千上万种。比如我要给表建哪些索引来加速查询，可索引建多了，写入就变慢，磁盘空间也会被吃光。还有控制运行时行为的各种旋钮，多少内存分给某个内存池、多少分给索引。这已经超出了任何单个人类推理能力的边界，更何况如果你面对的是成千上万个数据库，靠人去管根本不可能。
所以我们花了不少时间去研究怎么用机器学习来构建自动化工具。我们其实有两条研究路线，第一条是“黑盒”视角：不动数据库内部，只用它暴露出来的 API，看能对已有的 MySQL、Postgres、Oracle 做多少自动优化。第二条是“从零重建”：假设这个数据库天生就是被机器学习工具、也就是今天说的 Agent 来控制的，那系统的设计是不是应该略有不同？我们从优化 MySQL 里学到的很多东西，最后都被塞进了自己造的系统里。
当时做自动化工具最头疼的，是拿不到足够多的生产数据库数据，也没法把在一个部署上学到的东西迁移到另一个部署上。大多数人手上有两套环境：一套 staging 或者开发环境，一套生产库。你显然不敢在生产库上乱试，万一试出个性能退化，业务就挂了。所以你会先在 staging 上验证，再往生产上搬。但问题是，staging 和生产永远不是同一套硬件，也永远不是同一种负载。 这就是我们长期面对的核心难题：喂给模型、让它能在生产库上做出好决策的训练数据，永远不够。
然后 LLM 出现了，它彻底改变了这个问题的解法。因为 LLM 本质上是被互联网上所有关于怎么调数据库的博客文章、文档、最佳实践指南训练出来的。在研究层面我们发现，LLM 能帮你把调优这件事做到大概 85% 的程度，当然，总还有些奇奇怪怪的边角案例需要定制化算法去处理。
Matt：那是不是意味着，数据库已经可以很大程度上自我调优、自我优化了？
Andy：答案是肯定的，但这取决于你到底想要多大的提升。LLM 能帮你走到 80% 到 85% 的位置，那是不是永远还有更多性能可以榨出来？是的。有些人永远会在意那些边角的东西，因此我们过去构建的那些自动化方法对他们来说依然很重要。但对大多数人来说，其实一个让我非常意外的发现是：当年我们做初创公司、试图给 MySQL 做自动调优的时候，有多少人跑的就是亚马逊或者谷歌云平台上的开箱即用配置。他们跟我们说：“我以为亚马逊在帮我们调优啊。”不，他们没有。所以有足够多的人跑在默认配置上，那玩意儿简直糟透了，千万别那么干，而 LLM 恰好可以进来，处理掉一些显而易见的问题，在很短时间内给人带来有意义的改善。
Matt：在一个 Agent 会调用数据库、管理数据库，数据库本身也在走向自驱动的世界里，还有什么工作真正需要对数据库的深度理解？
Andy：即使你将来不打算成为数据库系统工程师，不去写 ClickHouse、Cockroach 或 Postgres 的内核，你依然应该去了解这些系统的内部原理。因为每个人都会和数据库系统打交道。如果你理解它们的内部实现、理解一个数据系统在给定查询下试图做什么、不做什么，你在理解整个技术栈时就会处于更有利的位置。
现在还需要上我那门课才能搞懂这些吗？不需要。Agent 已经把我所有的东西都吞进去了，它们可以把我教的一切原样吐出来。但说到底，无论你是通过传统大学课程学、自学，还是让语言模型教你，只要你理解了数据系统试图做什么，大部分神秘感就消失了。你会明白为什么查询跑得慢，或者为什么不慢，你在应用层面就处于更好的位置。
如果你读的是计算机科学或工程学位，专注于数据系统，我不认为“你要从零开始自己写一个系统”这个时代还会继续存在。不过，数据库公司仍然在招人来做这些事，因为总得有人理解 Agent 到底在干什么，并且能对它做的事做出判断。
Matt：我们是不是进入了一个数据库管理和部署完全不需要 Human in the Loop 的时代？
Andy：传统意义上我们熟知的 DBA 角色，我认为会被降级，其中很大一部分可以被自动化。但这不意味着这些岗位会消失，他们只是可以去做更高级的事情，比如数据建模，这永远重要。Agent 也能做很多建模工作，但你仍然需要有人来判断：这个数据模型是否真正捕捉到了我们组织或业务想在数据库中表达的东西？不过像调参数、选索引这种具体的事，可以交给 Agent 了。
为何在 ClickHouse 设立研究实验室
Matt：你最近加入了 ClickHouse，要创办 ClickHouse Labs。那么，为什么在一家商业公司里办实验室，而不是在学术界做这件事？
Andy：大学里做研究的本质，现在变得挺艰难的，美国的科研经费已经不是过去那样了。还有一个更大的问题：当一个 Agent 已经能做很多事的时候，招一个博士生到底意味着什么？当 Agent 能产出东西、能和我这个教授一起写论文的时候，你还需要那么多博士生来做这些事吗？我当然还是觉得教育学生有价值，我也喜欢做这件事，但我不清楚的是，我该怎么筹钱去养那么多我想要的学生。
有一些公司来找过我，问我有没有兴趣离开学校、和他们一起做点有意思的事。但那些邀请总是更像是“你要不要来我们这儿当个工程师”，或者说是我在研究方面想做的事的一个被稀释过的版本。然后我跟 ClickHouse 的人聊了，那个机会几乎好得不太真实。我说，你们是想让我来做研究？他们说，对，来做研究。我又说，研究这东西不一定总能出成果，我不知道会发生什么。他们说，太好了，去做吧。
这太疯狂了，因为你知道，他们不是早期创业公司，但也不是上市公司。通常来说，至少在数据库这个圈子里，公司都是等到已经站稳脚跟之后才会设立研究实验室。而他们愿意承担这种风险，或者说有这种“奢侈”，让我这样的人进来做同行研究，这太了不起了。
我现在处在一个观察期，在了解他们到目前为止构建的东西，因为他们还没怎么公开发表或写过自己做了什么。他们做了一些了不起的工作，我现在的任务是帮他们把这些工作转化成可以传播、可以发布到世界上的论文，同时开始启动更长期的、更具探索性的项目。
我在大学的时候，做的也是数据库系统里非常偏应用的工作，不是那种全世界只有十个人能看懂、跟现实毫无关系的理论研究。我想做的事情跟 ClickHouse 想做的事情直接相关，不只是 ClickHouse 系统本身，他们现在还有 Postgres 的产品线。我超级兴奋，因为我能产生直接影响，不用先写完论文，然后指望有人碰巧看到、采纳我们的成果。我们可以在真实的生产系统、真实的工作负载上评估一个想法好不好，如果确实有道理，我们就能在很短时间内把它推出去，这种机会对我来说太有诱惑力了。
Matt：2016 年的时候你曾经担心 ClickHouse 可能是“蒸汽软件”，因为它好得有点不真实，能给我们展开讲讲吗？
Andy：数据库是一个非常有意思的研究领域，因为我不只是在和其他大学的研究者竞争，还在和那些大科技公司竞争，微软、Google、Amazon 这些，再加上还有一堆创业公司，它们都有自己的数据系统。操作系统创业公司没多少，但数据系统创业公司多得很。所以我的工作就是，当一个新的系统发布时，去搞清楚它做了什么和我的研究不一样的地方？它哪里做得更好？我能从它解决问题的方式里学到什么？
当 2016 年 ClickHouse 发布的时候，我的反应是“这个东西像是从石头缝里蹦出来的”，凭空出现，却拥有所有这些能力：向量化执行、列式存储、压缩、compaction……几乎好得不像是真的，或者它一定是某个已有项目的 fork。但在 2016 年那会儿，根本不存在一个开源 OLAP 引擎能同时具备这些能力，所以这让我非常困惑。我当时就直接假设它是假的。当然，后来证明它是真的，而且显然带来了很多好处。
Matt：ClickHouse 非常快、非常实时。但为什么数据库，尤其是分析型数据库，通常在这方面很挣扎？
Andy：ClickHouse 的架构、核心基础，以 2026 年的标准来看已经不算新颖了，但在 2016 年绝对是新颖的。它的本质是，你要把数据以一种列式布局来存储。也就是说，你不是像行存那样，把一个元组里所有列的值连续地存在一起，而是把单个列的所有属性、所有数据连续地存在一起。然后用 CPU 上的向量化指令，在一条指令里同时处理多份数据，而不是去写 for 循环、低效地一个个跑。
再加上内置的压缩机制，以及它做日志结构存储的方式：先把一堆变更追加进去，因为你想让写入尽可能快，然后再在后台做 compaction，把它整理成更高效的存储形态。这些核心架构里的很多想法，其实都来自 Snowflake 当年做的工作，而在 Snowflake 之前，还有一个叫 VectorWise 的系统，最早叫 X100，后来由 CWI 商业化成了 VectorWise，就是那个造出 DuckDB 的学校。所以这些面向列存系统、分析系统、实时分析系统的想法，其实一直在往下流传。
但 2016 年的时候，没有任何开源项目把这些东西全都做齐了。所以当 ClickHouse 出来说“我们基于前人做的所有这些研究，把这些能力全都装进来了”，那真的非常惊艳。从那之后，DuckDB 有了类似的东西，阿姆斯特丹那帮人做了 Polars，Firebolt 一开始就是 ClickHouse 的一个 fork，他们重写了一堆内部实现，现在也有这些能力了，Databricks 也有自己的版本引擎，所以现在人人都有这么一套架构。
而我觉得 ClickHouse 这些年来做得特别好的一点是，它一直在把性能继续往前推，同时不断扩展它能真正支撑的工作负载。
Matt：从内部看，客户都在拿 ClickHouse 做什么？
Andy：人们用它来观测这些 Agent 产生的遥测数据，能够实时地对这些数据做出反应、对它们提出问题。金融市场上也有一大堆应用，欺诈检测，任何你需要快速写入数据、然后非常非常快地针对它提出复杂问题、并且要在毫秒级拿到结果的场景。我觉得把这两件事结合起来，让 ClickHouse 处在一个很独特的位置上。
Matt：ClickHouse 一直在走一条扩张产品线的路，它一开始是那个非常强大的 OLAP 实时分析数据库，现在它做了可观测性，收购了 Langfuse。你从内部是怎么理解这个演进过程的？这些东西真的能拼到一起吗？
Andy：在我决定加入 ClickHouse 之前，他们会在业务层面做一些事，比如他们有一个 Postgres 的托管服务，而不只是提供一个单一的、非常优秀的 OLAP 引擎；他们没有从 OLTP 领域起步，却把监控、可视化、可观测性这一整套栈都做了出来，不只是面向传统 BI 或传统数据，现在还覆盖了 Agent 和 LLM。他们正在做的所有事情，都是在向不同的垂直领域扩张，让这些垂直领域能够构建在 ClickHouse 平台之上。
Matt：似乎有一个趋势：Databricks 收购了 Neon，Snowflake 去年收购了 Crunchy。这种分析型数据库和事务型数据库的融合，是未来吗？它是被商业和业务原因驱动的吗，是为了能向同一个客户卖更多东西？还是说背后有一种产业化的产品逻辑？
Andy：这里其实有两个问题：一个数据库公司到底应不应该同时提供 OLTP 事务型系统和 OLAP 系统？以及，它们到底应该是同一套系统，还是分开的两套系统？
该不该做？我认为该做。回到我们刚才说的 Agent 能让你做什么，显然维护这些东西仍然是个挑战，但部署一个 Postgres 服务的门槛确实已经被大大降低了。
我还有一个猜想：对于一个从分析型数据库起步的创业公司来说，先去加一个 OLTP 能力，是不是比一个 OLTP 公司后来再去加 OLAP 能力更好？如果你想搭一套新的数据体系，先从分析做起，在那里获得增长，然后再去加 OLTP 的能力。我没法从商业角度严格证明为什么，但从商业上看，这似乎是更聪明的打法。
现在的问题是：你应该是单一 API、单一接口、一个逻辑端点，让人们在感觉上是单一数据库实例的东西上同时跑事务和分析？还是应该是分开的服务？ClickHouse 目前是分开的服务，但它们有一条快速路径，可以把数据从 Postgres 那边搬到 ClickHouse 里。而 Databricks 今年发布的是他们的 LTAP 引擎，或者说 Lakebase 的 LTA 故事，你可以在 Postgres、Lakebase 或 Neon 上跑事务，然后让 OLAP 引擎直接读取这些数据，这样你就不需要像 ClickHouse 或其他系统那样把数据复制两份。这种“两个引擎、一份数据”的想法并不新鲜，2010 年代有一家创业公司叫 Splice Machine，他们当时跑的是 HBase 加 Spark SQL，但只有一份数据，存在行存里。
人们从一开始就想要这种 HTAP 系统、这种混合系统。挑战始终在于：你怎么调和“一部分数据还在行存、一部分在列存”这个事实？像 Oracle、SQL Server 这种主流商业厂商，它们会存一份行存、一份列存，这叫“分片镜像”（fraction mirror）方案，然后有内部机制去同步。但这种混合方案一直没火起来，原因在于：组织里这两类工作负载的利益相关者，永远都想要各自最好的东西。跑应用、跑运营那边的 OLTP 团队，不想要一个“运营凑合、分析也凑合”的系统，他们想要最好的运营数据系统，不管好坏，现在那就是 Postgres。分析这边同理。所以这始终是这些混合系统在商业上、在 go-to-market 上的挑战。
不过我觉得 Databricks 可能处在一个有机会做成这件事的位置上，因为他们已经从分析侧、机器学习侧、数据仓库侧拿到了市场，现在只是把 OLTP 这块加进来。ClickHouse 也有可能走同样的路。这有点深入到数据系统架构的细节了，但所有人一直都想要这个东西，挑战往往不只是纯工程问题，也可能是组织原因或人的原因让你做不到。
向量、图与 GPU 数据库评级
Matt：我们再看看其他细分领域。你看好向量数据库吗？现在所有人都能做向量搜索了，这还是个值得投资的好生意吗？这些公司还能活下去吗？
Andy：我当教授那会儿，总能听到谁做得好、谁快不行了的传闻，通过投资人、前员工、去实习的学生、面试回来的人，东拼西凑出整个数据版图的样子。但现在作为投资人，我什么都看得见。据我所知，目前活得非常好的向量数据库公司是 Turbopuffer，他们极度专注于向量搜索，性价比远超其他所有人。
所以我不认为向量数据库会消失，它们会朝两个方向演化：要么变成像 Postgres、MySQL 那样的通用系统，成为记录系统，同时存原始元组和对应的嵌入向量；要么变成类似 Elasticsearch 的独立系统，从运营侧拉一份数据副本。这样它们就能舒服地作为“附加组件”存在，如果你想要极致性能，某些情况下还是得用这些专用系统。但我从没见过“Postgres 会被向量数据库干掉”的预测成真，恰恰相反。
Matt：那图数据库呢？Neo4j 都活了 20 年了，AI 时代本该是图数据库的高光时刻，现在发生了什么？
Andy：我在 Hacker News 上跟人打了个赌，他说到 2030 年图数据库市场会超越关系型数据库市场。如果成真，我就穿一件印着“我爱图数据库”的 T 恤，拿它当驾照、当大学证件，挂在网站上一辈子。现在是 2026 年，还剩 4 年，我很淡定，这不会发生。图数据库一直是小众市场。研究已经表明，只要在引擎里做某些优化，ClickHouse 做了，DuckDB 也做了一部分。图的遍历本质上就是表上的自连接，你可以实现得非常高效，轻松吊打 Neo4j。
说“比 Neo4j 快”有点像说"我比坐轮椅的人跑得快"，有点欺负人。现在 SQL 标准已经支持属性图查询，Oracle 是主要推动者，你可以在服务端做遍历。所以图数据库，我觉得是个糟糕的主意，没有任何理由真的要用它。
Matt：GPU 数据库呢？
Andy：GPU 数据库就是把查询执行全部下沉到 PCIe 上或同机、异机的 GPU 上跑。为数据系统造加速器的历史可以追溯到 1970 年代的“数据库机器”，人们造专用硬件跑排序和查询算子。到 1980 年代初就死掉了，等你设计并流片出新硬件，Intel 或摩托罗拉的下一代 GPU 已经出来了，收益就没了。
2010 年代又冒出一批 GPU 数据库创业公司，当时最大的挑战是你必须把整个数据库塞进 GPU 内存，一旦要穿过 PCIe 回传就慢得没法看。那批公司大多熄火了，剩下的专攻可视化。最近一年多，英伟达基本把那些苦苦挣扎的 GPU 数据库公司都收了，Voltron、HeavyDB……英伟达现在全力押注这个方向。但长期看，GPU 数据库系统这个思路还站不站得住，还有待观察。
微软公开在云上提供了 GPU 加速的分析服务；另一家大型数据库公司评估了 GPU 的经济性，决定不值得。我以前的一个学生现在在威斯康星大学当教授、休职去了英伟达，他们有个项目叫 SiriusDB，不是新数据系统，而是夹在现有系统和 GPU 之间的一层，支持把 DuckDB 查询跑在 GPU 上，也能跑 Doris、StarRocks、DataFusion。
难点在于：ClickHouse 期望的数据布局和 CUDA 想要的数据布局之间要做多少转换？不同组件之间怎么组织内存、共享内存？还有待观察，但研究热度确实很高。英伟达显然在推这个，因为能卖更多 GPU。现在大家要么算力受限、要么内存难求，计算硬件又贵又难拿，GPU 是所有硬件里最贵的。你说整个数据库都要跑在 GPU 上，至少短期内，我不确定这说得通。但如果性能提升足够显著，一些研究显示也许有意义。
Matt：有没有什么新兴品类，或者某个品类里大家都还没怎么聊到的细分机会？
Andy：你总能为新硬件造新数据系统，但我在这方面的战绩很烂。我们做过一堆实验性硬件的研究，结果不是被砍就是黄了。比如 Intel 的 Optane 持久内存，我们做了大量研究，如果假设 DRAM 是持久的，拔电不丢数据，那数据系统的构建方式会彻底改变，结果 Intel 把那条产品线砍了。我们还研究过存内计算硬件，就是内存条上直接带 CPU 核，数据系统可以把查询直接下推到 DIMM 上执行，我们搞的这个叫 OPM 的东西被高通收购后去年也砍了。
总有一堆围绕新硬件做数据系统的工作可做，这正是我在 ClickHouse 想搞清楚的事情之一：Agentic 工作负载跟人类或现有应用的工作负载，真的有那么大区别吗？如果有，为什么、怎么个不同法？你会怎么改数据系统的开发来更好地利用它？这还有待观察。查询优化永远是个有意思的难题，是数据系统里最难的部分；增量物化视图也是个大挑战。但这些不是没人想过，大家已经搞了几十年。所以对我来说，Agentic 这块可能是目前最有趣、最相关的方向，这些工作负载会带来什么变化、系统架构会怎么变？我还不知道。
数据库市场的未来
Matt：感觉数据库市场正处在一个特定的历史时刻。2010 年代，SQL 对 NoSQL 的演进是一场爆发式的活跃，然后是 Databricks、Snowflake 的出现，现在又有 ClickHouse。但看起来这股热潮稍微慢下来了，甚至可以说有点停滞。
Andy：也许吧，但我们以前也经历过这种趋势。1970、80 年代关系型数据库非常活跃，然后 90 年代又来了一波，之后市场就固化在那些大厂周围了，Oracle、IBM、Teradata，如果你只从这些公司的视角看数据库，那确实会显得停滞了很多年。但就像你说的，2000 年代、2010 年代又有大量活动。
不过，如果拿 AI 作为参照系，那所有东西看起来都像停滞了，因为计算机科学史上从来没有过 AI 这样的东西。这就像给一只猎豹喂了一堆可卡因，再把它塞进法拉利里，人们开发这些东西的速度简直疯狂。所以相比之下，其他一切都会显得慢、显得死、显得停滞。但归根结底，我认为体量会非常重要。
你刚才提到成本和效率，比如在给定硬件上榨取最好的性能、努力降低成本，这始终是个有意思的挑战，可以一直做下去。但最终，我不认为数据本身会发生那种需要我们把数据库领域已知的一切全部推倒重来的巨变，就像你不会发明一套新的算术来取代 1+1=2 一样。关系模型本身就是你想要表示数据的基础，你只能在这个基础上变化实现方式。所以，让这些系统变得更高效，肯定还有大量工作要做，但我不认为你会需要重新发明它。
总有人想取代 SQL，我觉得这可能是个注定失败的事业。不过，SQL 有可能变成像汇编语言那样的东西，就像现在没人再手写汇编一样，因为 text-to-SQL 已经做得足够好了。
你可以想象这样一个世界：我不再需要为每个应用都配一个通用数据系统，而是为这一件事 vibe coding 出一个完全专门化的数据系统。你现在其实已经能看到这种做法的影子了，代码生成，或者针对查询某些部分的即时编译（JIT），有些系统已经在做了，ClickHouse、Postgres、Umbra 都有。但如何让这种高度专门化变得可持续，可能是未来一个更大的研究问题。
Matt：所以一方面这是个有点停滞的行业，另一方面，这一层本身比以往任何时候都更重要，这也正是为什么你的朋友 Larry Ellison 能成为接近世界首富的人。Oracle 远不止是一家数据库公司，他们的总部大楼就是数据库的形状，这本身就说明了数据库的根本重要性。
Andy：而且没人试图认真取代 Linux，虽然有各种小众操作系统，但没有人大规模地试图完全替换 Linux。但数据库不一样，总有人觉得能比别人做得更好，总有新想法冒出来。所以我不会说它停滞了，我只是说，短期内很多精力会集中在 Postgres 上，我们可以对它做一些改进。但与此同时，我仍然认为会有这些专门化的引擎存在。我不知道下一个工作负载是什么，我不清楚 Agentic 工作负载是否真的有那么大不同，因为它们建模的东西，跟过去设计应用的方式差不多。向量查找跟过去有本质区别吗？你需要额外的算子、额外的索引，但也就那样。我不知道下一个东西是什么，但我相信一定会有。
Matt：那未来五年呢？是不是意味着 ClickHouse 这类公司只要继续变得更好、更稳固就行了，因为根本需求还在，不会再有新一波小创业公司了？
Andy：当你说“更好”的时候，其实有两种含义。一种是现有的查询能不能跑得更快？能，ClickHouse 还有改进空间，其他系统也一样。但 ClickHouse 在做的架构，跟 Snowflake 2013 年做的、Databricks 基本在抄的那些东西，在高层上是相似的，大家在分析这块做的其实是同一件事。
真正重要的是数据系统周边的东西：用户界面、开发者体验、数据摄入、与其他系统的互操作。Snowflake 成功的一部分原因，就是它把这些周边的东西做得特别好。所以，真正重要的往往是数据库管理系统基础之上的那层脚手架。这不是研究，但这是 ClickHouse 这些年来一直在做得更好的事情，它帮助扩展了系统的适用范围。