TL;DR. On October 2, 2026, Supabase announced it is acquiring Turso, the company that rewrote SQLite from the ground up in Rust, alongside a $150 million round led by GIC. The logic: agents create databases at a rate nobody provisions for, so give each agent its own SQLite database at birth and offer Postgres as the graduation path. The engineering for that path is now funded. The governance for it is not: a SQLite file carries no roles, no grants, no policies, so everything that makes a production database governed gets built after the workload already exists.
Supabase acquires Turso at a moment when its own numbers make the reasoning plain. The company says it now launches more than one million databases a week, and the funding coverage puts it at 4 million a month, with 70% of new databases created by agents or AI-driven tools. Paul Copplestone's announcement describes agents "spinning up millions of databases to power the prototypes, explorations, dashboards, and apps they're building." The majority user of the platform is no longer a person, and the deal buys infrastructure sized for that user.
What Supabase bought
Turso's pitch has been consistent for a year: SQLite is the right shape for an agent's database, and stock SQLite is not good enough at it. The company rewrote the engine from the ground up in Rust and attacked the limitation that matters most when many writers share infrastructure. SQLite allows a single write transaction at a time; Turso's rewrite added MVCC, and the 0.8 release on September 29 shipped BEGIN CONCURRENT, letting transactions commit in groups. Pekka Enberg's benchmarks on a 12-core machine with synchronous = FULL put 99.9th percentile write latency at 2.4 ms across 32 connections, against 1.2 seconds for stock SQLite, and throughput at 9,500 transactions per second across 64 connections against roughly 1,370.
The cloud side matters as much as the engine. Turso Cloud runs a diskless architecture with the write-ahead log on object storage, loads a database on demand, and suspends it when inactive, which is how a single server manages millions of databases. Customers like Superhuman, Sauna.ai, CTO.new, and Mastra already provision databases per agent or per project on it. Glauber Costa's farewell post states the design point in six words: "One agent, one task, one user." Isolation by multiplication: instead of many tenants sharing one database behind a permission model, every tenant gets a database and the boundary is the database itself.
That economics argument is why the per-agent database is SQLite and not a smaller Postgres. A Postgres database arrives attached to an instance: a running process with shared memory, a WAL, background workers, a port. Scale-to-zero platforms shrink the idle cost but keep the floor. An embedded engine has no floor; a database is a file, and a suspended database is a file nobody has open. At four million new databases a month, the difference between a cheap process and no process is the whole business model.
Three vendors, three isolation primitives
This is the third acquisition-or-launch in three weeks built on the same premise. Cockroach Continuum pools thousands of virtual clusters on shared hosts, betting that agents multiply the count of databases faster than the load on any one of them. Google's AlloyDB preview hands each agent an ephemeral, read-only Postgres node served from separate storage segments. Now Supabase buys an embedded engine so each agent can have a database that costs nearly nothing to create and nothing to keep.
The premise is shared; the isolation primitive is not. Cockroach isolates with a tenant-prefixed keyspace inside one engine. Google isolates with a disposable compute node over shared storage, writes excluded. Supabase, after this deal, isolates with a separate engine entirely: the agent's database and the production database do not even speak the same dialect. That makes the Supabase version the cheapest at birth and the most expensive at the boundary, because moving a workload from the agent tier to the production tier means changing engines, and the announcement names that path as the point: a single path "from a small database for an agent to a full-fledged production workload."
The graduation path. Almost everything an agent creates dies quietly; the few databases that matter cross an engine boundary, and the boundary only moves what SQLite can represent.
Graduation is a migration, and migrations drop things
Calling the path "single" names the developer experience, not the mechanics. SQLite to Postgres is an engine migration, and the two engines disagree about things a schema quietly depends on. SQLite's type system is dynamic: a column's declared type is an affinity, not a constraint, so a TEXT value can sit in an INTEGER column for months without complaint until a Postgres COPY refuses it. Date and time values are whatever convention the writing code chose. Booleans are integers. That looseness is part of what makes SQLite small enough to hand to every agent, and it means the data that graduates is data whose actual shape nobody has checked, written by a program that no human was watching.
The sharper gap is the one nothing in the file can carry. SQLite has no roles, no GRANT, and no row level security; access control is file permissions, and isolation between agents is the one-database-per-agent boundary itself. The moment a workload graduates to Postgres, that boundary stops doing the work and a permission model has to exist. Someone, or more likely something, now writes the grants, the policies, and the ownership structure for a schema that an agent designed. We have already measured what happens when that step is skipped at scale: 16,326 Supabase databases sat publicly readable because the SQL creation path left row level security off and the applications worked anyway. That incident involved one engine and human-adjacent developers. The graduation path adds an engine change, and the schema author was a machine.
Governance has to attach at birth
The instinct is to govern the production tier and let the agent tier stay wild: scratch databases are scratch. The creation numbers say why that posture will not hold. When 70% of new databases are agent-created and the successful ones are promoted, the production estate's future schemas are being designed right now in the ungoverned tier. Whatever naming, typing, and structural conventions the agents converge on is what graduates. Reviewing meaning at promotion time means reverse-engineering what the agent intended weeks earlier, with the agent's session long gone. The cheaper point to capture intent is the moment of creation, when the agent that knows why the table exists is still running.
There is also a bookkeeping problem that no per-database tool addresses. An estate growing at this rate needs an answer to questions catalogs were never built for: which of these databases still exists, which graduated, which contain copies of production data an agent pulled in for analysis, and which are about to become production themselves. Catalogs assume databases are few, long-lived, and worth documenting one at a time. A fleet of short-lived embedded databases breaks every one of those assumptions, and the vendors selling the fleet are, reasonably, selling provisioning rather than an answer.
None of this argues against the acquisition, which looks like the right infrastructure bet on its own terms. Supabase says nothing changes for existing users, Turso Database stays open source, and the integration details, including what the graduation tooling actually preserves, are unannounced. Vendor growth figures deserve their usual discount. The direction, though, matches what Cockroach and Google already committed to: the database count is the axis that grows now, and the per-database assumptions in your tooling, capacity, backup, catalog, and access review all break at a different point on that axis.
Where Datapace fits
A database per agent solves isolation by multiplication, and multiplication is exactly what makes meaning and permissions hard to track. Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. If agents are already creating schemas in your estate, the place to start is knowing what exists and what it means: see estate documentation.
Sources
- Supabase, Supabase is acquiring Turso, Paul Copplestone, October 2, 2026 (rationale, one million databases a week, millions per server, customer list, team, continuity).
- Turso, Turso is joining Supabase to give every agent its own database, Glauber Costa, October 2, 2026 (ground-up rewrite, diskless WAL on object storage, one agent one task one user, open source continuity).
- Turso, Turso 0.8: Concurrent writes without SQLite's single-writer bottleneck, Pekka Enberg, September 29, 2026 (BEGIN CONCURRENT, MVCC, group commit, latency and throughput benchmarks, test setup).
- TipRanks, Supabase Raises $150 Million and Acquires Turso to Scale Agentic Database Infrastructure, October 2, 2026 (round and investors, prior Series F timing, monthly database and user figures, 70% agent-created share, leadership role).