云厂商给 Agent 的数据库原语，可能一开始就选错了

Databricks 工程副总裁、Neon 联合创始人 Nikita Shamgunov 在 MTS 的访谈里说得很直接：云厂商货架上那套原语，不适合 Agent 的使用方式。

原访谈在 YouTube，时长 15 分 29 秒：MTS 访谈。X 上的原帖在这里。

他说的原语，可以理解成云上现成可拿的积木。虚拟机、托管数据库、对象存储、消息队列，这些东西为传统应用设计。Agent 的用法不一样。它会反复启动数据库、试错、丢弃、再开一个。按 Nikita 给出的数字，平台上有 15 万个新数据库启动，1500 万次启动和停止。这个量级下，低端负载如果又慢又贵，Agent 的实验循环就转不起来。

Lakebase 的两个关键点就落在这里。一个是低端足够便宜，按需启动，用完就停。另一个是数据库分支。Neon 团队最早把分支做进数据库，Agent 可以给生产库开一个临时分支，在分支里改数据、跑任务，结果要么合回去，要么直接丢掉。数据库分支相当于给 Agent 一个可回滚的沙箱，不用碰生产环境。

有网友在回复里说，数据库分支这事来得太晚，整个技术栈都落后于 Agent 的速度。这个抱怨不算离谱。Agent 已经把写代码、调工具、跑任务的节奏拉快了，数据库层的试错还在用共享实例和手工回滚，确实不匹配。

Nikita 还提到，微软的 Horizon DB 也采用了类似架构。他的说法是，Lakebase 不只服务 Agent，也能接企业级负载。技术上，Lakebase Postgres 仍然是 Postgres，但把存储和计算拆开，存储放在对象存储上，分支做在存储层。这样做的结果是，系统可以在不同层之间移动瓶颈。他提到写入吞吐提升了 3 到 5 倍。对在线事务处理这类传统负载，他的解释是，创新集中在存储和调度层，Postgres 本身的性能特征还在。

这套叙事里有一个更大的类比。过去从本地机房迁到云， lift and shift 也能跑，但只有云原生才能吃到弹性和成本优势。现在 Agent 应用也在经历类似迁移。Agent 需要沙箱、记忆、工作流、数据库状态，云厂商的通用积木能用，但不顺手。数据库状态是硬问题，因为 Agent 一旦开始执行多步任务，状态就变成核心。

访谈里还提到 AI 软件工厂。代码生成工具正在变成批量生产软件的平台，但软件最后仍要落到基础设施上。今天的软件跑在今天的基础设施上，明天的 Agent 工厂会挑更适合自己的基础设施。数据库分支会不会变成标配，接下来要看真实负载里的表现，不看发布会的词。