Cloud Providers’ Database Primitives for Agents May Have Been the Wrong Choice from the Start
In an MTS interview, Databricks’ Nikita Shamgunov makes a judgment call: off-the-shelf database primitives from cloud providers are not suitable for agents. Lakebase uses database branching, storage-compute separation, and low-cost cold starts to drive down agents’ trial-and-error costs while also trying to handle enterprise workloads.
Databricks VP of Engineering and Neon co-founder Nikita Shamgunov put it bluntly in an MTS interview: the primitives on cloud providers’ shelves are not suited to how agents are used.
The original interview is on YouTube and runs 15 minutes 29 seconds: MTS interview. The original X post is here.
His “primitives” can be understood as off-the-shelf building blocks available in the cloud. Virtual machines, managed databases, object storage, and message queues were designed for traditional applications. Agents use them differently. They repeatedly start databases, try things, discard them, and start another. According to the numbers Nikita gave, the platform had 150,000 new databases started and 15 million start and stop operations. At that scale, if low-end workloads are slow and expensive, the agent’s experimentation loop cannot keep spinning.
Lakebase’s two key points land here. One is that the low end is cheap enough: start on demand and stop when done. The other is database branching. The Neon team was the first to build branching into the database; an agent can open a temporary branch of a production database, change data and run tasks in the branch, and then either merge the results back or simply throw them away. Database branching is essentially a rollback-capable sandbox for agents, without touching the production environment.
A commenter in the replies said database branching came too late and that the entire stack is lagging behind the speed of agents. That complaint is not unreasonable. Agents have accelerated the pace of writing code, calling tools, and running tasks, while trial and error at the database layer still relies on shared instances and manual rollbacks. That is indeed a mismatch.
Nikita also mentioned that Microsoft’s Horizon DB uses a similar architecture. He says Lakebase does not only serve agents; it can also handle enterprise workloads. Technically, Lakebase Postgres is still Postgres, but it separates storage and compute, puts storage on object storage, and implements branching at the storage layer. The result is that the system can move bottlenecks between layers. He mentioned a 3x to 5x improvement in write throughput. For traditional workloads such as online transaction processing, his explanation is that innovation is concentrated in the storage and scheduling layers, while Postgres’s own performance characteristics remain.
There is a larger analogy in this narrative. In the past, when moving from on-premises data centers to the cloud, lift and shift could also run, but only cloud-native approaches could capture the advantages of elasticity and cost. Now agent applications are going through a similar migration. Agents need sandboxes, memory, workflows, and database state. Cloud providers’ general-purpose building blocks can be used, but they are not a good fit. Database state is the hard problem, because once an agent starts executing multi-step tasks, state becomes central.
The interview also mentions the AI software factory. Code generation tools are becoming platforms for mass-producing software, but software ultimately still has to land on infrastructure. Today’s software runs on today’s infrastructure; tomorrow’s agent factories will choose infrastructure that fits them better. Whether database branching becomes standard will next depend on performance under real workloads, not on launch-event rhetoric.
发布时间: 2026-11-07 04:29