Supabase Acquires Turso to Serve AI Agents
Supabase is acquiring Turso and says it now launches over a million databases a week, most of them created by AI tools rather than people.
Supabase announced on 2 October 2026 that it is acquiring Turso, the company that rebuilt SQLite in Rust. The stated reason is not a feature gap. It is that the typical creator of a new database is no longer a developer clicking through a dashboard, it is an AI agent doing it automatically. Supabase says it is already launching over one million databases per week. That number is the whole story of the deal.
What Supabase acquired, and what Turso is
Turso is a database company with a specific trick. It took SQLite, the small embedded database that normally lives as a single file inside one application, and rebuilt it in Rust so that a single server can hold enormous numbers of those databases at once, loading one when something asks for it and suspending it when nothing does.
That design matters when databases are cheap and numerous rather than large and few. A traditional Postgres instance expects to be long lived and busy. A per-user or per-agent database expects to be idle almost all the time and to cost nothing while idle.
Supabase says Turso's team is joining and that Turso founder Glauber Costa will lead the agentic infrastructure effort. Alongside the acquisition, Supabase raised a further $150 million led by GIC, with CapitalG, IronArc and SquarePeg participating, reported a few months after its $500 million Series F.
Why agents changed the shape of the problem
When a person builds an app, they create one database and grow it. When an agent builds an app, it creates a database as a side effect of a task, and it may do that hundreds of times while iterating. Coverage of the round puts roughly 70 percent of new Supabase databases as created by agents or AI-driven tools rather than by hand.
Two things follow from that, and they are the reason a SQLite company was worth buying:
Provisioning has to be instant and effectively free. If spinning up a database takes 30 seconds and costs money whether or not it gets used, an agent that creates 200 of them is a billing incident.
Isolation becomes the default rather than an architecture decision. Giving each tenant, each preview, or each agent run its own database is only sane if databases are tiny and suspendable.
This is the same pressure showing up elsewhere in the stack. It is why hosted sandboxes and ephemeral environments have become products in their own right rather than internal plumbing, a shift worth understanding on its own terms if you are choosing infrastructure now.
What this changes if you are building today
Short answer: nothing this week. Longer answer: it tells you which way the defaults are moving, and the defaults are what you inherit.
If you are | What the deal implies |
|---|---|
Running one Postgres database for one app | No action. Postgres remains the main product and nothing announced deprecates it. |
Building multi-tenant and arguing about tenant isolation | Per-tenant databases are getting cheaper to justify. Revisit the assumption that a shared schema is the only affordable option. |
Letting an agent create and migrate schemas | Expect per-branch and per-run database copies to become normal. That is a safety gain, because an agent can wreck a copy instead of your data. |
Picking a database this month | The decision criteria have not changed. Pick on your access patterns, not on an acquisition. |
If you are at that last stage, the practical questions are still the boring ones, and they are covered in our guide to choosing a database for an AI-built app. If you started on SQLite because an AI builder defaulted you there and you are now outgrowing it, the move is documented in migrating from SQLite to Postgres.
The part nobody in the announcement says out loud
A world where agents create a million databases a week is also a world where agents misconfigure a million databases a week. The volume that makes this deal commercially obvious is the same volume that makes access control the main risk in AI-built software.
That is not hypothetical. Researchers have repeatedly found live, publicly readable Supabase databases behind AI-built apps where row level security was never switched on, which we covered in exposed Supabase databases in vibe-coded apps. Cheaper and more numerous databases do not fix that. They multiply it. The fix stays the same: check what is readable before you ship, not after.
Turso's own documentation remains the best primary reference for the embedded model if you want the technical detail, and Supabase's announcement post is short enough to read in full rather than through summaries. For keeping track of releases like this without reading twenty newsletters, we keep a standing method in how to keep up with AI news.
How did this land?
About the author

Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.


