Agent-Native Data Infrastructure & Lakebase

In a traditional setup, getting a new database requires a ticket to a DBA, a provisioning script, and several minutes of waiting. That model falls apart when an agent needs a fresh database for each task it runs — potentially thousands of times per day. The control plane exposes a simple API that agents call directly. Create a database. Fork it from a parent. Delete it when the task ends. A coordinator agent can spin up one isolated database per subtask, keep the blast radius contained, and clean everything up automatically when it is done. No human involvement, no waiting, no sprawl.

The key technical idea is changing what "a branch" means at the storage level. In a traditional database, a branch means copying data — which means copying gigabytes or terabytes. That is slow, expensive, and fundamentally incompatible with agents that need to branch hundreds of times per minute. Lakebase branches work on a different principle. Every write to a database goes into a write-ahead log — a sequential record of changes. A branch is nothing more than a pointer to a specific position in that log. Two branches share all the same underlying data pages until one of them writes something. At that point, only the pages that changed diverge — everything else is still shared. This is called copy-on-write. The result: forking a 10TB database is just as fast as forking an empty one. There is no data to copy, only a pointer to set.

Even after solving the branching problem, there is still a cost problem with compute. A traditional database server runs continuously — it uses CPU and memory even when no queries are happening. An agent fleet might have thousands of databases, most of which are idle most of the time. Running all of them as always-on servers is extremely wasteful. Serverless compute solves this by treating database compute as something you rent per request. When a query arrives, a compute node starts up, handles the query, and then shuts itself down after a period of inactivity. Storage is completely separate from compute — it lives in cheap object storage and is always available. An idle database costs almost nothing, which makes large agent fleets economically viable.