Move Fast and Don't Break Things: Scaling Databases for the AI Era — PlanetScale
Ben Dicken of PlanetScale argues that teams can move fast without breaking production, combining isolation, redundancy, sharding, back pressure, and decoupling with AI agent workflows such as VSchema-driven sharding, Traffic Control budgets, schema branching, and one-click reverts. His core claim is that good developer experience produces good primitives for AI.
Ben Dicken from PlanetScale opens with the phrase “move fast and break things,” which dates back to early Facebook engineering culture, and argues that the trade-off no longer has to be binary. His premise is that a team should be able to ship quickly, build great features, and still keep the databases, infrastructure, and application servers underneath healthy. He notes that this matters more now that AI agents generate and deploy code on our behalf and drive explosive traffic growth, with products doubling, tripling, or growing 100x in months. He is explicit that this is an infrastructure talk rather than one about inference or agent orchestration, and that the aim is a status page showing three to five nines of availability.
Reliability principles: isolation and redundancy
The first principle is isolation. Ben separates the data plane, where the critical data lives and users log in and interact, from the control plane, observability pipelines, analytics, apps, and MCP servers. His point is that a well-run database platform is unlikely to fail, but the components teams ship to most often are the ones most likely to break. A bad deploy to the control plane should therefore never take down the data plane.
The second principle is redundancy. Stateless application tiers, such as Cloudflare Workers, Vercel functions, and AWS Lambda, are easy to scale and replicate. Databases are harder because they must store state reliably, and “you can’t lose a single bite of data.” The standard approach is a primary node receiving most traffic, with replicas or followers standing by in different data centers or availability zones to take over. He makes a scale argument: a single database server failing once every couple of years at a small app becomes a weekly or monthly event across thousands of servers, so failover has to be designed in from the start. He stresses that these principles apply at every point on the growth curve, from 100 users to millions of daily actives, even if the specific technologies change.
Scaling: sharding, back pressure, and decoupling
Sharding is presented as the core scaling technique, and the one PlanetScale uses most for large customers. A single node works at 10 GB but not at 10 TB, 100 TB, or a petabyte. The solution is to spread data and queries across many shards behind an intelligent proxy that routes requests. PlanetScale does this through Vitess for MySQL and Neki for Postgres. Ben adds that each shard should itself be redundant, with a primary and several replicas, so a single shard can self-heal quickly.
Back pressure is framed as a mix of scalability and reliability. Popular databases such as MySQL, Postgres, and SQLite often crash when overloaded by too many queries, CPU use, or RAM pressure, which takes every user down with them. Back pressure means the system detects when it has crossed a resource threshold and deliberately pushes back by rejecting queries or connections. Existing users and critical traffic stay healthy while other traffic degrades gracefully. He calls this arguably the most important principle in the database layer, and says the rest of the stack must be built to handle the rejections.
Decoupling is the third principle. Ben acknowledges the convenience of consolidating OLTP, analytics, queues, jobs, and caching into one system, but warns that a single failure can then bring everything down. Resource contention is also a problem: a burst of queue jobs should let teams scale queue compute without scaling everything else. Independent scaling of each backend component follows from decoupling.
Giving agents control of infrastructure
The talk’s final section asks how agents can safely take partial or full control of the most critical infrastructure. Ben acknowledges this is intimidating because a database mistake is not fixed by clicking a rollback button. He argues that good primitives make this safe.
For sharding, he describes Vitess and its VSchema, which he calls “literally a JSON file” that specifies sharding columns, sharding methods, and which tables go on which shards. Because agents are good at reading and writing JSON and text, a developer can give an agent a schema and ask it to prototype a VSchema. Once it is deployed, PlanetScale’s API and CLI provide the interfaces to create and scale sharded systems. The complexity stays under the hood while the configuration stays simple.
For back pressure, he cites a GitHub post about 2x to 4x traffic increases attributed largely to AI agents, on top of already enormous load. PlanetScale’s answer is Traffic Control, which lets teams tag and categorize incoming traffic and set resource budgets for CPU and backend processes for each segment. When a segment exceeds its budget, the system warns the client to slow down, or it can kill executing queries. Ben concedes that denying requests is not ideal but is far better than a total outage.
For schema changes, PlanetScale mirrors the git workflow with database branching. A developer or agent branches the schema, makes changes in isolation, and merges them to production through a deploy request with no downtime. If a problem appears, a one-click revert returns the database to its prior state without data loss. The APIs and CLI let agents automate branching, pull requests, and code review in step with a mirrored database state, whether that automation is fully autonomous or human-in-the-loop.
Closing argument: developer experience as AI primitives
Ben closes by redefining developer experience beyond themes and keyboard shortcuts. He means giving the person responsible for a company’s database the tools to deploy safely, avoid mistakes, and improve performance. His thesis is that when developer experience is focused on this core, the result is also strong primitives for AI agents to operate databases safely and reliably. PlanetScale exposes these capabilities through an MCP server as well as CLIs, so both humans and agents work with the same operational surface.