既要快速交付，也要稳住数据库：PlanetScale 谈 AI 时代的扩容与安全变更

简要描述Brief Description

快速行动，但不要破坏任何东西：为 AI 时代扩展数据库——PlanetScaleMove Fast and Don't Break Things: Scaling Databases for the AI Era — PlanetScale

目录Table of Contents

• 简介
  Intro
• AI 规模的服务中断
  Outages at AI scale
• 三个部分
  Three parts
• 关于 PlanetScale
  About PlanetScale
• 隔离
  Isolation
• 冗余
  Redundancy
• 分片
  Sharding
• 背压
  Back pressure
• 解耦
  Decoupling
• 赋予智能体对基础设施的控制权
  Giving agents control of infrastructure
• 设计 VSchema 的代理აგენტ
  Agents designing a VSchema
• 流量控制
  Traffic Control
• 为数据库创建分支
  Branching your database
• 还原时不会丢失数据
  Reverts without data loss
• 良好的开发者体验有助于智能体发挥出色。
  Good DX is good for agents

简介Intro

大家好，最近怎么样？希望大家在 AI Engineer 的最后一天过得愉快。嗯，我今天想聊的是如何快速行动，又不把事情搞砸。“快速行动，打破常规”这句话，你们可能以前听过。它源自 Facebook 早期的工程文化，对吧？当时的理念是，我们要能够快速开发、快速发布，而不受数据库宕机或某些功能出故障之类问题的限制，因为快速发布的价值实在太大了。这是 20 年前的事了，对吧？那时候还没有 AI 智能体替我们编写代码、发布产品并代我们部署。所以，如果说有什么变化的话，那就是如今这个理念比以往任何时候都更适用。但在我看来，我们其实可以兼顾两者，对吧？Hey everybody, how's it going? Hope you're having a good last day of AI Engineer. Uh what I'm going to talk about today is how to move fast and not break things. So the the phrase move fast and break things. You've probably heard this before and what this uh refers to is it's a phrase from early Facebook engineering culture days, right? And the idea was we want to be able to move fast and ship fast and not be constrained by, you know, databases going down or breaking certain features because the priority is there's so much value in shipping fast. And this was 20 years ago, right, before we had AI agents writing code for us and shipping things and deploying things on our behalf. So, if anything, the idea of doing this is more true than ever. But in my opinion, we can actually achieve both, right?

我希望能够快速发布、打造出色的功能并交付给客户，同时又不把现有东西弄坏。I want to be able to ship fast, build great features, get things out to my customers, but also not break

人工智能规模的服务中断Outages at AI scale

数据库、基础设施、支撑我所做工作的应用服务器。我们大概都见过类似这样的情况。我并不是在针对任何特定公司。过去短短六个月、一年、两年里，我们见证了近乎疯狂的规模增长：日活跃用户翻了两倍、三倍，甚至十倍、一百倍。其中很大一部分是由 AI 智能体带来的需求推动的，基础设施因此难以跟上。而这其中有些问题纯粹是因为这确实很难解决。我的意思不是要特别点名批评谁，把系统扩展到服务数千万乃至数亿用户本来就很难。但我们希望打造出能良好扩展、服务大量用户的优秀产品，也希望我们的状态页面能更像这样，对吧？the databases, the infrastructure, the application servers that are powering what I'm doing. And we've probably all seen something that looks approximately like this. And I'm not calling out any particular company. There's a number of companies right that due to the kind of insane scale that we've seen over the past even 6 months year two years right where we've had like daily active users double triple 10x 100x a lot of that powered by like the demand of AI agents um where the infrastructure struggles to keep up and some of this is simply because it's a very hard problem right this is not meant to call anybody in particular out it's hard to scale things to tens of millions or hundreds of millions of users but what we'd like to have is great products that scale well for lots of users and have our status pages look a little bit more like this one, right?

三个或四个 9 的可用性，呃，也许是五个 9 的可用性——我们的数据库运行健康，应用程序运行健康，最终用户也满意，对吧？这就是我想谈的话题背后的想法，它和你们参加过的大多数演讲可能都有些不同。很多演讲可能都在谈推理，或者具体讲如何使用智能体或不同类型的自动化来完成任务。这场演讲更多是关于基础设施的，但会讲你如何做到这一点并快速交付，同时满足 AI 智能体带来的需求，以及你如何利用 AI 智能体来完成所有这些事情的需求。Three or four nines of availability uh maybe five of availability where our databases are healthy, our applications are healthy and ultimately our users are happy, right? So this is kind of the idea behind what I want to talk about which is a little different than probably most of the talks you've been at. A lot of the talks are probably talking about inference or specifically how to do things with agents or different kinds of automations. This is more of an infrastructure talk, but how you can do that and ship fast both with the demand of AI agents as well as the you being able to use AI agents to make all of

三个部分Three parts

让这些流程更加优化、更加顺畅。我想谈谈这件事的三个方面。首先，无论用户数量多少，究竟该如何构建不会总是宕机的系统？接着，假设你要打造下一个爆款应用，让它能够扩展到数百万人使用，我们该如何运用这些相同的原则来实现扩展？最后，我们又该如何把这两件事交给 AI 智能体来做，或者至少让它们参与其中、协助完成？我想我也应该先简单介绍一下自己，以及我为什么要谈这个话题。these processes more optimized and smoother. So, there's three parts to this that I want to talk about. The first one is how do you even build systems regardless of the number of users you have that aren't going down all the time? and then tying that into well okay if you're going to build the next hit application that's going to scale to millions of people using it how do we scale that using these same principles and then finally how can we take these two things and let AI agents do them for us or at least in part work with them in doing this so I should probably introduce myself a little bit too why I'm talking about

关于 PlanetScaleAbout PlanetScale

我是 Ben，来自 PlanetScale，我们做数据库，这是我们的全部业务。我们与很多发展极快的 AI 公司合作，比如 Cursor，并为他们提供数据库支持。因此，作为一家公司，我们非常认真地看待这件事：如何扩展规模并支持那些平台拥有数百万用户的公司？我谈到的一些内容，来自我们去年发表的一篇文章，文章介绍了我们运营数据库的理念。我建议你去 Google 搜索一下并读读那篇文章。嗯，我们来看看其中的几条原则。this is I'm Ben and I'm from planet scale and we do databases this is our whole thing and we work with a lot of these AI companies that are scaling extremely fast. We work with companies like cursor for example and power databases for them. And so this is something that we as a company take very seriously. How do we scale and support companies that have millions of users uh on their platforms and some of what I'm talking about comes from a article that we published last year about kind of our philosophy of how we operate databases. I would encourage you to go Google that and read that. Um but a couple of these principles let's go over some of these.

隔离Isolation

所以，首先，最重要的一点之一就是隔离，对吧？运行基础设施时，你要确保的一件事是，搭建的系统要做到：如果某个部分发生故障，不会导致整个系统瘫痪，而是让每个组件都高度隔离。我这里展示的是数据平面。简单来说，就是你的数据库在哪里？你最关键的数据存放在哪里？这些数据是用户登录并与你的应用交互时所必需的。但系统里还有很多其他组件，对吧？有控制平面、可观测性管道，可能还有分析框架、应用、MCP，以及各种可能发生故障的组件。事实上，假设你使用的是不错的数据库平台，那么数据库发生故障的可能性应该比较低；但其他这些你更频繁地发布和部署的东西，就更容易出故障。So the the first and one of the most important is isolation. Right? When you are running infrastructure, one of the things you want to make sure you do is have a setup where if something fails, it doesn't take down the whole system, but every component is very isolated. So what I'm showing here is data plane. That basically means where are your databases? Where does your most critical data live that you need to be using for your users to log in and interact with your application? But there's lots of other components, right? There's your control planes, there's your observability pipelines, there might be your analytics frameworks, there's your apps, there's your MCPs, and there's all these different components that can potentially fail. And in fact, assuming you're using a good database platform, the database is hopefully low likely to fail, but these other things you're shipping and deploying to more frequently, so are more likely to fail.

所以我们要确保设计得当：即使我把一个有问题的服务部署到控制平面并导致其宕机，也不会影响其他任何东西，而且仍然可以访问数据库，对吧？我的数据平面中的任何东西也是如此。所以这就是……So we want to make sure that we've designed things where if I deploy a bad ship to the control plane and take it down, nothing else is impacted and can still access the database, right? And anything in my data plane. So this is

冗余Redundancy

这是我们非常重视的一项核心原则。另一点是冗余。如果你们以前用过数据库，可能见过类似这样的图。类似的原则也适用于应用基础设施和其他基础设施。不过，对于应用服务器来说，冗余通常更容易解决一些，因为它们处理的是无状态负载，对吧？许多自动扩缩容的 Cloudflare Workers、Vercel Functions 和 AWS Lambda 都能轻松扩展并实现冗余，因为它们不存储状态。但在数据库领域，你必须可靠地存储状态，不能丢失哪怕一个字节的数据。那么该怎么做呢？嗯，一种非常常见的做法成本更高、也更复杂，但这是可靠扩展的方式：设置一个主节点。one of these kind of core principles that we take very seriously. And another thing is redundancy. And if any of you have worked with databases before in the past, you've probably seen a diagram that looks something like this. And similar things apply to your app infrastructure and your other infrastructure. Although in the case of application servers, usually redundancy is a little bit easier to solve because it's a stateless workload, right? There's lots of sort of autoscaling cloudflare workers and versell functions and AWS Lambda that can scale and have redundancy very easily because it's not storing state. But in the database world, you have to store state reliably. You can't lose a single bite of data. And so how do you do this? Um, a very common approach which costs more money and is more complex but it's the way that you scale reliably is by having a primary node.

因此，你的大部分流量都会流向这里。不过，你总会在不同的数据中心或不同的可用区安排好备用的副本服务器或从服务器，以便随时接管，因为服务器有时确实会发生故障。嗯，在小规模场景下，如果你的应用只有一百名用户，并且只有一台数据库服务器，你可能每隔几年才会遇到一次故障。但在大规模场景下，如果你有数千台服务器，那么一年发生一两次的故障就会变成每周或每月都会发生的故障。因此，你需要建立完善的系统来妥善应对这类情况。好，我们已经聊过构建可靠的可扩展系统，或者说打造可靠系统所遵循的原则。但问题是，我刚才讲的这些内容，完全可以写成一本书。So this is where most of your traffic goes to. But you always have replica servers or follower servers standing by in different data centers or different availability zones ready to take over because the fact is servers do fail sometimes. Uh, and on a small scale when you've got an app that has a hundred users and you have one database server, you might only experience a failure once every couple of years. 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. Okay. So we've talked about uh what the principles of of scaling reliably are or of um having reliable systems are. But then the question is what I've just told you here we could write a whole book on.

对吧？所以还有很多内容，确实有人整个职业生涯都专注于这个领域。我们现在讲得稍微快了一点，但无论你处在这张用户增长图表的哪个阶段，这些原则都适用，对吧？你可能只有 100 个用户，即便如此，做好冗余、隔离和容错，对这批规模较小的用户来说依然很有价值。等用户增长到这里时，你也要贯彻同样的原则。我不知道你能不能看清那条线，但这里表示的是每日活跃用户达到数百万。不过，发展到某个阶段，你确实需要引入不同的技术，才能高效、有效地扩展系统。那么，我们接下来花几分钟聊聊如何扩展这些系统。你们最期待的部分大概是 AI 智能体，我们会在最后讲到。Right? So there's lots more that you know there's people who spend their entire careers focused on this. So, we're going a little bit quickly through it, but these principles apply no matter what point of this user growth chart you're at, right? You could be at 100 users and in this case, uh, it's still good to have redundancies, to have isolation, to have failure even for that smaller set of users. And you want to apply those same principles when you are all the way up here. I don't know if you can see that line very well, but at millions of daily active users. But there is a point where you actually have to incorporate different technologies to scale efficiently and effectively. So, uh, let's talk about how we scale those systems for a few minutes. And probably the part you're most excited about is the AI agents part, which we'll get to at the end.

嗯，其中一项关键工作——也是我们在 PlanetScale 经常做的——就是分片。嗯，我刚发现鼠标还在屏幕上，我把它移开。看……Um, so one of the key things, and this is what we do a lot of at Planet Scale, is sharding. Um, I just realized my mouse is on the screen, so let me get that off the screen here. See

分片Sharding

如果这最终会消失的话。嗯，接下来聊聊数据库分片。这是什么？你要做的，是不再依赖单个节点。数据量只有 10 GB 时，单个节点运行得很好；但当数据量达到 10 TB、100 TB，甚至 1 PB 时，情况就不一样了。那么你该怎么做？你需要把数据和查询分散到多台服务器上。下面这些就是分片。通常，你会在中间放置某种代理——稍后我们会详细介绍 VTGate——由它智能地将所有用户请求或查询请求分发到这些服务器上。这正是我们在 PlanetScale 为一些大型客户大规模提供的服务。我们通过 Vitess 为 MySQL 分片，通过 Citus 为 Postgres 分片。if that will go away eventually. Um, so database sharding. What is this? What you do is instead of relying on that single node, which works fine when you have 10 gigabytes of data, it doesn't work so well when you have 10 terabytes of data or 100 terabytes of data or a pabyte of data. So what do you have to start doing? Well, what you need to do is spread your data and your queries out across many servers. And so that's what all of these shards down here below are. And typically you put some kind of proxy and we'll talk more about what VTGate means later in between that intelligently handles distributing all of the user requests or the query requests across all of these servers. Uh and this is exactly what we do a lot of for some large customers at planet scale. We do sharding through vitess for my SQL and niki for postgress.

嗯，所以这是一种非常基础的分片方式。但还有一点是，你不会单独使用分片。如果我们看这个例子，比如分片 A，在这个方框里，你实际上会希望有一个冗余系统。因此，其中会有一个主节点和几个副本。这样，如果其中一台服务器发生故障，这个分片就能自我修复，并在出现问题时迅速恢复上线。这是我们常见的一种数据库扩展方式，而且可能也是最常见、性能最高的方式。但实际上，同样的原则——把查询和数据分散到许多服务器、许多节点、许多磁盘上——也适用于许多其他……Um and so this is a very fundamental way of doing sharding. But the other thing is you don't just use sharding by itself. If we look at this and we see for example shard A, within that box, you actually would want a redundant system. So you'd have a primary and several replicas in there. So if one of those servers fails, that single shard can do self-healing and get back online very quickly if there's a problem. So this is one of the ways that we see and is probably the most common and performant way to scale databases. But really the same principle of hey let's take queries and data and spread them out across many servers, many nodes, many drives uh applies to lots of other

背压Back pressure

你正在构建的技术栈中的各个部分。背压。这是另一个既与可扩展性有关、又与可靠性有关的方面。我们的意思是，MySQL、Postgress 和 SQLite 这类非常流行的数据库系统，在过载时往往处理得不太好。一旦查询过多、CPU 使用率过高，或者在很多情况下缓存用尽了 RAM，如果没有做好充分的防护，它们就会直接崩溃。这样一来，你的服务器就宕机了，所有用户都会受到影响，无法使用由该数据库支撑的服务。所谓背压，就是设计系统，使其能够主动施加压力并作出响应：当检测到资源使用超过某个阈值时，系统可以主动拒绝请求、拒绝查询或拒绝连接，这样就能让现有用户或部分流量保持正常运行，同时优雅地降低其他流量的服务质量。然后，你的技术栈其余部分也必须能够支持这种机制。areas of the stack that you're building. Back pressure. So this is another one that is sort of a mix of being a part of scalability but also a part of reliability. And what we mean here is there's a lot of systems like MySQL and Postgress and SQLite, these very popular databases that people run that don't do a good job at handling being overloaded. The moment that they have too many queries or using too much CPU or they run out of RAM for the cache in many cases, if not taken a lot of care for, they'll just crash and now your server is down and now all of your users are impacted and they can't use your service that the database is powering. What back pressure is is it's designing a system to be able to push back and say when I detect that I'm above a certain threshold of resources I can actually say I want to push back and start failing requests denying query uh denying connections right so that I can keep the existing users or some of the traffic healthy while gracefully degrading some of the other traffic and then the rest of your stack has to be built to support that.

所以，这是一个适用于技术栈许多领域的原则，但在数据库中，它可以说是最重要的。呃，我们看看。翻页笔。好了。接下来，在我们开始讲如何借助 AI 完成这一切之前，我想谈谈它的最后一个组成部分，那就是】【。So, this is a principle that applies in lots of areas of the stack, but in the database, it's arguably the most important. Uh, let's see here. The clicker. There we go. And then the last component of this that I want to talk about before we move into how to do this all with AI is

解耦Decoupling

解耦。嗯，你会和很多人交流；谈到数据库时，他们会说，最好把所有服务都整合到一起，因为这样有一些便利之处。比如把 PostgreSQL 数据库、OLTP 工作负载、分析任务，以及队列和作业系统、缓存都放在一起。这样确实方便，有些技术也试图把这些功能整合到一处。但这不仅会增加很多复杂性，还会破坏前面提到的一些基本原则，比如故障隔离，对吧？如果一个服务宕机，实际上就意味着所有东西都会宕机。你还得处理资源争用的问题。比如队列中的作业突然激增，你需要扩展队列，但其他部分可能根本不需要扩展。这时，如果能独立扩展后端服务各个部分所分配的计算资源，为你最喜欢的应用提供支持，那就再好不过了。decoupling. Uh, there's a lot of people that you'll talk to and when it comes to databases will argue that you should probably have all of your services combined into one because there's some convenience to that. your Postgress database, your OOLTP workloads combined with what you're doing for analytics combined with your your queuing and your job system, your caching. There is convenience and some technologies try to do this where we put this all in one. But that does one add a lot of complexity, but it also breaks some of the fundamental principles from earlier like failure isolation, right? If one service goes down, that actually means everything is going down. And then you also have to deal with contention of resources. So if you suddenly have a burst of Q jobs and you need to scale up your cues, but maybe nothing else really needs to scale, it would be nice if we can independently scale the amount of compute resources that we've given to each of these parts of our backend service powering your favorite application.

对吧？所以这并不是一份完整的清单。到目前为止我们讲了什么？我们讲了分片、背压，现在正在讨论解耦。可扩展性还有许多其他方面。同样，你完全可以把整个职业生涯都投入到成为可扩展性专家上。呃，不过，在 PlanetScale，我们经常会深入思考这些问题，因为客户依赖我们提供可靠且可扩展的服务。最后，我们来讲这一部分的最后一个主题。假设我们已经落实了所有这些原则：我们以可靠的方式开展工作，具备容错能力，也能实现很强的可扩展性。但如今，许多组织都是如此；我们也和很多人交流过，他们无论是在小规模团队还是大型组织中，都有这种感受。Right? So this is not a complete list. What did we go through so far? We went through sharding. We went through back pressure. And now we're talking about decoupling. There's many other aspects to scalability. And again, you could spend your entire career becoming an expert in scalability. Uh, but this is a lot of what we think about a lot at planet scale because our customers rely on us to be reliable and to scale. So, finally, let's go to the last part of this. We let's say we have all of these principles in place. We are doing things reliably where we have fault tolerance. We're doing things that are very scalable. But these days in a lot of organizations and we talk to a lot of people that feel this both at the small scale and at very large organizations.

让智能体控制基础设施Giving agents control of infrastructure

我们如何才能让智能体部分或完全掌控你们公司可以说最重要的基础设施，对吧？数据库、队列，以及支撑你们技术栈其他所有层的东西。嗯，这件事可能会让人有点忐忑，因为如今用 AI 编写代码基本上已经成了常态，对吧？有些情况下，人们甚至不再亲自写任何代码了，对吧？AI 实际上会编写你的所有代码，审查你的所有代码。嗯，你只是在引导这些智能体完成这些工作。但要说“我现在还要让智能体能够部署数据库变更、修改数据库的配置，或者对数据库进行分片”，这就大不一样了，对吧？因为如果它们在这方面出了错，通常可不是点一下按钮就能回滚那么简单，对吧？How can we allow agents to whether in part or in full have control over what is arguably the most important infrastructure of your company, right? The databases, the cues, the things that are powering every other layer of your stack. Um, and this is something that can be a little bit intimidating because it's pretty much the standard these days, right, to write code with AI. In some cases, people are not even writing any lines of code anymore, right? AI is actually writing all of your code, reviewing all of your code. Um, and you're just sort of guiding these agents to doing that. But it is quite different to say, I'm going to now also give my agents the ability to deploy changes to the database or make changes to how things are configured there or to shard my database, right? because that's something if it gets wrong, it's generally not as simple as clicking a button to roll it back, right?

这会导致整个应用瘫痪，所有用户都会察觉到。因此，我们希望有效且安全地完成这件事。接下来，我会重新回顾之前提到的几个概念，并思考如何利用智能体来解决这个问题。回到分片的话题，我想更具体地谈谈 Vitess。这是一个开源项目。呃，我们为客户运营测试数据库，它与 MySQL 配合使用来实现分片。你可以看到下面所有这些分片，它们都是 MySQL 数据库；而 VTGate 是代理，它本质上是一个智能代理，可以解析 MySQL 查询，判断查询应该发往哪个分片，并以非常复杂的方式路由所有请求。因此，这款软件相当复杂，但我们提供的用于指定如何……的接口……It's taking down your entire application and every user notices. So, we want to do this effectively and safely. So, I'm going to revisit a couple of the concepts that I previously talked about and think about how do we use agents to solve this. So, going back to sharding, what I'm going to talk a little more specifically about is Vitess and this is an open- source project. uh we operate the test databases for our customers and it works with my SQL to do sharding. So what you can see here is like all of those shards down there those would be my SQL databases and the VT gate that's the proxy that is basically an intelligent proxy that takes my SQL queries parses them figures out which shard they need to go to and routes all of those requests in a very sophisticated way. So the software is fairly complicated, but the interface that we present for specifying how do

设计 VSchema 的代理ակալAgents designing a VSchema

如果你想让所有查询和数据都进行分片，其实相当简单。这就是我们所说的 VSchema，它本质上是一个 JSON 文件，你可以在其中指定要依据哪个列进行分片，以及想采用哪种分片方式；你还可以指定哪些表放在哪些分片上，并对配置的位置和方式进行大量控制。好处是，众所周知，AI 智能体非常擅长处理文本文件和 JSON 文件。因此，你可以把文件交给智能体，说：“嘿，我的数据库扩展性遇到了问题。这是我的 schema，帮我设计并创建一个不错的 VSchema 原型。”对吧？等你设计出一个经过深思熟虑的方案，并确定在 PlanetScale 这样的平台上最高效的分片方式后，只要把它接入并部署即可。我们还提供了一个界面，用于创建新的分片系统并扩展数据库。借助我们提供的 API 和命令行界面，这些流程中的许多环节都可以在 AI 的帮助下完成，也可以交由 AI 掌控。you want all of your queries and your data sharded is actually quite simple. It's what we call a v schema and it's literally a JSON file where you say here's the column I want to shard on and here's the way I want to do sharding and you can specify certain tables to go on certain shards and have lots of control over where and how things are configured. And the great thing is, as we all know, AI agents are excellent at working with things like text files and JSON files. So you can give your agent and say, "Hey, I'm struggling with scalability of my database. Here's my schema. I want you to come up and help me prototype a good v schema." Right? And once you've developed and designed something that it has thought through and made decisions about the most efficient ways to shard when you are on a platform like planet scale you literally will plug this in and you make a deploy and you you can we give you an interface for creating new sharded systems and scaling up your database and a lot of this can happen with either the help of AI or letting AI take some control over these processes uh given our API and our command line interface that we run.

所以，这就是那种事情，对吧？底层实际上是非常复杂的基础设施，负责扩展你的系统；但只要为它提供合适的接口，比如简单的配置文件，这些东西对任何想要扩大规模的公司来说都会容易接触得多。嗯，还有一件事，这就谈到了我们之前提过的背压概念，对吧？当数据库过载时——你可以想象，这种情况在其中一些公司可能一直都在发生，对吧？我记得几个月前 GitHub 发过一条推文，大意是说，他们的流量比原本就已经极高的负载又增长了两三倍，甚至四倍。而这几乎全都归因于 AI 智能体，对吧？所以他们本来就有庞大的基础设施，因为他们是全球最受欢迎的开发平台。So this is one of those things right 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. Um, another thing, so this is getting into the uh concept of back pressure that we talked about earlier, right? So when a database is overloaded, and this, as you might imagine, probably happens all the time at some of these companies, right? I think there was a a tweet a couple of months ago from GitHub that basically said like their traffic had like two or three or 4x from what already was an extremely high load. And pretty much all of that was attributed to AI agents, right? So they already had gigantic infrastructure because they're the most popular place in the world to develop.

然后他们的流量出现了多次增长，尤其是在假期期间，对吧？这是因为这些系统过载了。那么我们该如何应对呢？我们的解决方案之一，也是我们喜欢采用的一种思考方式，就是……and then they had multiple uh uh traffic increases especially over like the holidays right due to these uh overloaded systems. So how do we deal with this? One of our solutions and the way that we like to think about it is we

流量控制Traffic Control

为用户提供一个名为流量控制的系统，让你基本上可以对所有进入数据库的流量进行分类和标记，然后创建资源预算，比如规定“这部分流量使用的 CPU 资源或后端进程不能超过这个额度”，一旦超出，我们也会进行优雅降级。我这里展示的是一张图表：我设置了一个预算，规定资源使用量不能超过这些额度，并在开始超出时发出警告。图表显示的是一段时间内超出预算的查询数量。我们会向客户端发送警告，比如“嘿，系统过载了，你需要减慢速度”。我们还可以进一步收紧限制，直接终止正在执行的这些查询。give users a system called traffic control which allows you to essentially categorize and tag all of the traffic coming into your database and then you create resource budgets to say hey this segment of my traffic cannot exceed this amount resources of CPU usage or of backend processes and again we do graceful degradation when that happens. So what I'm showing here is this is a graph of I have a budget set up um to say don't exceed these amount of resources and warn if I do start exceeding these resources. So it's showing me uh this is the amount of queries that are exceeding your budget over time and we're we're we're sending warnings back to the client like hey I'm overloaded you need to slow down and we can even make it more strict where we actually kill those queries that are executing.

对吧？这就是那种情况，嗯，虽然不得不拒绝请求并不理想，但总比整个应用宕机、所有用户都无法使用要好得多。呃，最后还有一件事我想谈谈。我知道我这里展示的是 PlanetScale 的 UI，但这件事其实并不只是针对 PlanetScale，而是……Right? And this is one of those things that like, okay, it's not ideal to have to deny requests, but it's much better than your whole application going down and being offline for all of your users. Uh, and then finally, one other thing I I want to talk about, and I know I'm showing this is the planet scale UI here, but this is not even so much specifically about planet scale, but

对数据库进行分支Branching your database

这关乎我们使用智能体来完成这些工作的理念。大多数开发者在构建应用时都习惯采用类似 Git 的工作流，这同样适用于你的智能体，对吧？你有一个 main 分支，然后创建一个分支、修改代码、将修改合并进去，再动态部署到应用所在的位置。早在智能体出现之前，我们就希望把同样的用户体验应用到数据库上，因为开发新功能时，你往往也会修改数据库架构：添加表、添加列、删除内容、添加索引……为了让数据库与你的代码库保持同步，你会对数据库做各种修改。因此，借助前面提到的同一套 Vitess，我们为你提供了对数据库架构进行分支管理的能力：你可以在隔离环境中修改架构，然后通过我们称为“部署请求”的机制，将这些修改合并回生产环境。it's about the philosophy of how we do these things with agents, which is most developers are used to using a gitlike flow when you're building. And this applies to your agents as well, right? You have a main, you create a branch, you make code changes, you do merge that in, and you deploy that dynamically to wherever your application is deployed. What we have done, and this was long before agents even existed, is we wanted to take that same UX and mirror that for your database because a lot of the times when you're building new application features, you're also making changes to your schema. You're adding tables, you're adding columns, you're deleting things, you're you're adding indexes, you're doing all of this stuff to your database to keep it in sync with your codebase. So what we give you powered by that same vitess earlier is the ability to branch your database schema, make changes to that schema in an isolated environment and then merge that back into production with what we call a deploy request.

所有这些都无需停机。不仅如此，实际上还具备这种能力，你可能会在这里看到……All with no downtime. And not only that, but actually the ability, you might see here at the

可在不丢失数据的情况下回滚Reverts without data loss

底层还具备这样的能力：如果你部署了架构变更后发现问题，我们可以让你一键回滚，恢复到数据库的旧状态，而且不会丢失数据。呃，这对人类用户来说非常实用；此外，我们也提供了 API 和 CLI，让智能体能够自动完成这些操作。这样一来，当它们执行任务、自动编写代码、创建分支、提交拉取请求和进行代码审查时，就可以有一个与所有这些操作同步运行的镜像数据库状态，对吧？这一过程可以完全自动化，也可以半自动化。显然，我们很多人采用的都是有人参与的工作方式，也就是人类仍会审查 AI 智能体所做的所有更改，这是一件好事。嗯，不过，我们已经准备好了构建这类系统所需的基础组件。bottom, the ability to, if you deploy a schema change and you see a problem, we give you the ability to oneclick revert that go back to the old state of your database without data loss. Uh, and so this is something that was great for humans, but we also have the APIs and the CLI to be able to let agents automate this. So when they are doing things and automating code and branching and making pull requests and doing code review, there can actually be a mirror database state that is working in sync with all of those things, right? And that can either be fully automated, it can be semi-automated. Obviously, many of us are working in a human in the loop fashion where humans are still reviewing all of these changes that AI agents are making, which is a good thing. Um, but we have the primitives in place for building these uh systems.

还有不少其他事情我没来得及谈，不过我想提出的最后一点是：我们是一家公司，而且我知道很多……And there's a number of other things that I didn't get to to talk about this, but kind of the the ending point that I want to make is we're a company and I know a lot of

良好的开发者体验有利于智能体Good DX is good for agents

市面上有些公司喜欢专注于开发者体验。我说的开发者体验，不只是指浅色和深色模式切换、好用的键盘快捷键之类的东西，而是指这样的实际体验：如果你是负责公司数据库或某项基础设施的开发者，我们有没有提供你所需的工具，让你避免出错、安全地进行部署、提升数据库速度和性能？呃，我们多年来一直在打造这些工具。事实证明，当你真正专注于开发者体验的核心时，最终打造出来的基础能力，也非常适合让 AI 安全、可靠地操作数据库，并帮助数据库扩展。呃，我们通过 MCP 服务器和命令行界面开放了许多这样的功能。显然，关于哪种方式更适合与 AI 智能体协作，大家有不少争论；但由于我们向双方都开放了这些功能，因此无论是管理数据库，还是与 AI 智能体顺畅协作，体验都很出色。companies out there like to focus on the developer experience. And when I say developer experience, I don't just mean like light and dark mode switches and good keyboard shortcuts and all of this, but I mean the actual experience of, hey, if you're a developer that's responsible for your company's database or responsible for some piece of infrastructure, do we give you the tools that you need to not mess up to do deploys safely to make your database faster to get better performance? Uh, and we've been building these things for years. 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. Uh, and so because we expose a lot of these things through our MCP server, through command line interfaces, obviously there's plenty of debate on which of those is better when working with your AI agents, but because we expose those things to both parties, it's actually a great experience for operating your database and working well with AI agents.

我想说的就这些。感谢大家到场。我是 Ben，祝大家在接下来的会议中一切顺利。So that is all that I have to say. Thank you guys for coming. I'm Ben and have a great rest of the conference.