In 2022 I built mvSQLite, the massively scalable, time-traveling SQLite-compatible distributed database. Three months later, in November, OpenAI released GPT-3.5, and four years later AI agents are everywhere. People deploy agents and ask their agents to build and deploy apps every day - at a pace several orders of magnitude faster than in the pre-LLM era.
Now I'm building Willow, the agent harness for Bridge. It turns out that AI agents are the perfect kind of workload for SQLite, and multi-tenant agent harnesses are the perfect kind of workload for mvSQLite.
Entropy is bad
LLMs destroy information when they work. A good agent harness compensates for that by making some or all information undestroyable:
- Permission requests and automatic pre-exec reviews (Claude Code)
- Fine-grained sandboxing (Codex)
- Just give it a computer (Claude Code Web, OpenClaw on Mac minis and VMs)
Willow takes a fourth approach: it keeps the state of an agent's virtual filesystem at every point in time in persistent storage, as an SQLite table (with large blobs offloaded to S3). Thanks to how mvSQLite stores multi-versioned data, reading the filesystem snapshot at any past point in time incurs no extra cost compared to reading the current version.
Suppose a user accidentally tells the LLM to delete a document, then asks for it back. The LLM will issue three tool calls to look up the file at an earlier version and copy it back:
GetVersionAtTimestamp("3 days ago") = "00003a6ed63a7951ffff"
Read(path = "/artifacts/doc.md", version = "00003a6ed63a7951ffff")
Copy(
src_version = "00003a6ed63a7951ffff",
src_path = "/artifacts/doc.md",
dst_path = "/artifacts/doc.md"
)
Those twenty hex characters are an mvSQLite version: an 8-byte FoundationDB read version followed by a 2-byte batch ID. Every snapshot of the agent's filesystem is addressable by one of these - until it falls outside the database's retention window and the old page versions get garbage collected.
Agent execution is embarrassingly concurrent
Agent loop execution is a kind of "embarrassingly concurrent" workload - it's light on CPU, spends most time waiting for LLMs, and perfectly shardable. Willow packs up to 1,000 agents per OS process, each with its own SQLite database backed by mvSQLite.
Although SQLite isn't good at high-throughput concurrent read-write transactions - even with mvSQLite's page-level optimistic concurrency control - agents are single-threaded by nature, and the LLM token generation that drives each write is 100x–1000x slower than the write itself. For now.
LLMs understand SQLite
The mvSQLite client library is vanilla libsqlite3.so with a different VFS plugged in. LLMs are well-trained on SQLite, so it's easy for them to write code and generate apps assuming a SQL backend they already know.
Willow leans into this. Every agent-deployed website - the kind a user gets from "build me a habit tracker and deploy it" - is served straight out of the agent harness, and the application data lives in a dedicated mvSQLite database alongside the agent's filesystem.
Serving in production
Willow can serve millions of agents and agent-generated web apps, all on mvSQLite.
SQLite has always been popular in local-first apps - but historically not so much for serving production traffic, due to operational complexity and a poor fit with modern cloud patterns.
mvSQLite does not have any of those problems. It delegates the hard work - data replication, backups, high availability, and (most of) transaction processing - to FoundationDB. Clients are stateless - they do not touch the local disk, open and close databases in milliseconds, and an unused database costs only the storage it occupies.
It's basically decoupled compute/storage - making a transaction on an mvSQLite database is more like reading or writing an EBS volume. The more common cloud-SQLite pattern keeps a synchronized local file on each compute node, which is the right shape for one big database with many readers, and the wrong shape for a million small databases that any node might need to claim a moment from now.
In 2022 mvSQLite was a database looking for a workload. AI agents turned out to be it - each one its own SQLite, its own history, its own filesystem, by the million. Willow is what we're building on top - try it through Bridge if you are interested!