跨国深谈← 返回←快速迭代，但别把数据库搞挂

快速迭代，但别把数据库搞挂

关联

人物 Ben

公司 PlanetScale

概念 智能体 · 分片 · 背压 · 隔离 · 冗余 · 解耦 · 开发者体验

“快速行动，打破常规”，这句话你可能听过。它出自早期 Facebook 的工程文化，意思是：尽快发布产品，别让数据库、基础设施拖后腿。

那是 20 年前。现在 AI 智能体已经开始替人写代码、做部署，这件事比以往任何时候都更成立。

演讲者 Ben 认为，两个目标其实可以兼得：跑得快，但别把东西搞坏 。

Ben 来自 PlanetScale，一家做数据库的公司，客户包括 Cursor 这类正在疯狂扩张的 AI 公司。

过去半年到两年里，很多公司的日活用户翻倍、翻十倍、翻百倍，背后很大一部分是 AI 智能体带来的流量，基础设施经常跟不上。

他的演讲分三部分：怎么构建不出故障的系统、怎么把它扩展到百万用户、以及怎么让 AI 智能体参与其中。

为什么隔离是第一条原则？

跑基础设施时，要保证一个部件坏掉不会拖垮整个系统。数据库本身——如果用的是靠谱的平台——反而不太容易挂。

更容易出事的是那些你频繁改动的部分：控制面、可观测性管道、应用、MCP 服务。

设计得好，就算一次糟糕的部署把控制面搞挂，数据库照常服务，别的什么都不受影响 。

服务器多了，故障就从几年一次变每周一次

第二条原则是冗余。应用服务器是无状态的，用自动扩缩容很容易做到冗余。

但数据库必须可靠地存数据，一个字节都不能丢。

常见做法是设一个主节点承接大部分流量，同时在不同的数据中心或可用区里放若干个副本节点随时待命。Ben 提醒：

小规模时，100 个用户加一台数据库服务器，可能几年才遇到一次故障；

规模大了，几千台服务器，故障就变成每周、每月的事，必须有应对机制 。

数据涨到 10TB 以上，就得分片

单个数据库节点在 10GB 数据时工作得很好，到 10TB、100TB 就不行了。

办法是分片：把数据和查询分散到很多台服务器上，中间放一个代理，把请求智能地分发出去。PlanetScale 用 Vitesse 做 MySQL 的分片，用 Niki 做 Postgres 的分片 。

而且分片不是单独使用的——每个分片内部还要有自己的主节点和副本，某个服务器坏了，这个分片能自我修复，很快恢复上线。

过载时，宁可拒绝部分请求，也别整个崩掉

MySQL、Postgres、SQLite 这些流行数据库，一遇到查询太多、CPU 或内存耗尽，很多时候直接就崩了，所有用户一起遭殃。

反压的意思是：系统检测到资源超过阈值时，主动拒绝一部分连接和请求，让存量用户继续正常使用，其他流量优雅降级。

不理想，但比整个应用下线好得多 。

别把所有东西塞进一个数据库

有人主张把交易数据库、分析、队列、缓存全合在一起，图方便。但这破坏了故障隔离——一个服务挂，全都挂。

而且各部分会抢资源：队列任务突然暴涨时，你只想扩队列，不想被迫扩整个系统。解耦之后，每个部分可以独立伸缩 。

AI 智能体能不能碰数据库？

现在用 AI 写代码已是常态，有人甚至一行代码都不写了，只是引导智能体。

但让智能体去改数据库、改配置、做分片，风险完全不同——搞砸了不像代码那样点一下回滚就行，可能整个应用瘫痪，每个用户都看得见 。

Ben 的答案是：给智能体简单、安全的接口。比如 Vitesse 的分片配置叫 vschema，就是一个 JSON 文件，指定按哪一列分片、怎么分。

AI 智能体最擅长的就是处理 JSON——你可以直接说：我的数据库撑不住了，这是我的表结构，帮我设计一个分片方案 。

数据库也能像代码一样分支、合并、回滚

开发者熟悉 Git 流程：开分支、改代码、合并、部署。PlanetScale 把同样的体验搬到了数据库上：

给表结构开分支，在隔离环境里加表、加列、加索引，然后通过部署请求合并回生产环境，全程不停机。

更关键的是，部署后发现有问题，一键回滚到旧状态，不丢数据 。

这套本是为人类设计的，但现在通过接口和命令行，智能体也能自动化整个流程——它改代码、开分支、发请求做代码审查时，可以有一个同步变动的数据库状态。

可以全自动，也可以半自动，很多人仍然让人类审查每一步变更，Ben 认为这是好事 。

专为人类做好用的工具，恰好也适合 AI

结尾 Ben 说，他说的开发者体验不是深色模式或快捷键，而是：

如果你负责公司的数据库，工具有没有给足你不出错、安全部署、提升性能的能力。

PlanetScale 为此构建了很多年，结果发现，这些为人类打磨的核心体验，恰好也是让 AI 安全可靠地操作数据库的最好基础 。

本集带走

• 隔离、冗余、反压、解耦，是不管用户多少都适用的可靠性原则
• 规模一大，故障频率随之上升：几千台服务器时，故障变成每周的事
• 分片是扩展海量数据最常见也最高效的方式，每个分片内部还要有冗余
• 让 AI 操作数据库的关键是给它安全接口：JSON 配置、类 Git 的分支合并、一键回滚
• 为人类做好的开发者体验，天然就是 AI 智能体友好的基础设施

但在大规模下，当你有数千台服务器时，一年一两次的故障就变成了每周或每月一次的故障，所以你需要有相应的系统来很好地应对这种情况。
But at a large scale, when you have thousands of servers, a once or twice a year failure becomes a weekly or monthly failure, and so you need to have systems in place to deal with this very well.
—— Ben · [05:41]

在某些情况下，人们甚至不再亲手写任何一行代码了。AI 实际上在写你的所有代码，审查你的所有代码，而你只是在引导这些智能体去做这些事。
In some cases, people are not even writing any lines of code anymore. AI is actually writing all of your code, reviewing all of your code, and you’re just sort of guiding these agents to doing that.
—— Ben · [11:44]

所以这是那种——底层现实中是非常复杂的基础设施在扩展你的系统——但只要你为它提供合适的接口，比如简单的配置文件，这些能力对任何想要扩展的公司来说都变得容易接触得多。
So this is one of those things, very complex infrastructure in reality under the hood that is scaling your systems, but you provide the right interfaces for it, like simple configuration files, and those things become much more accessible to any company trying to scale.
—— Ben · [13:55]

我记得几个月前 GitHub 发过一条推文，大概说他们的流量比原本就已经极高的负载又涨了两三倍甚至四倍，而这几乎全部归因于 AI 智能体，对吧？
I think there was a tweet a couple of months ago from GitHub that basically said like their traffic had like two or three or four x from what already was an extremely high load, and pretty much all of that was attributed to AI agents, right?
—— Ben · [14:22]

而且结果某种程度上证明，当你真正专注于开发者体验的核心时，你最终得到的东西同时也是非常好的原语，能让 AI 安全、可靠地与数据库协作并帮助它扩展。
And it does kind of turn out that when you really focus on that core of the developer experience, what you actually end up with is also very good primitives for AI being able to work with a database safely and reliably and helping it scale.
—— Ben · [18:12]