Supabase is acquiring Turso, and the per-agent database just got a Postgres landlord
Supabase is acquiring Turso, the team that rebuilt SQLite in Rust for millions of tiny databases. Both products continue unchanged for now, but the plan is clear: lightweight SQLite for agent tasks, Postgres when workloads grow.
Supabase announced on October 2 that it is acquiring Turso, the company that rebuilt SQLite in Rust and runs a cloud where a single server can host millions of small databases. The thesis is narrow and worth taking seriously: AI agents create databases faster than traditional provisioning was designed for, and Supabase appears to be betting that the answer is two engines under one roof rather than stretching Postgres to fit every job.
What was announced
Supabase says it is now launching more than one million databases per week, and it frames the deal around that demand. Turso founders Glauber Costa and Pekka Enberg join Supabase, with Costa leading what both companies call agentic infrastructure. Financial terms were not disclosed. SiliconANGLE reports the acquisition alongside a $150 million funding round led by GIC, with CapitalG, IronArc, and SquarePeg participating, and describes Supabase as having agreed to buy Turso. Neither company post gives a closing timeline, so the deal status is best read as announced rather than complete.
The product line is the more important detail. Supabase continues building on Postgres. Turso continues building on SQLite. Turso’s cloud platform keeps running, and both companies tell existing users that nothing changes today. Turso adds that its database remains open source and actively developed, and that deeper integration with Supabase should arrive “in the coming months.”
Why SQLite and Postgres under one roof
Turso’s architecture is built for the shape of agent workloads: many small, short-lived databases that should be cheap to create, loaded on demand, and suspended when idle. Postgres is a poor fit for that pattern at scale, because each instance carries real memory and connection overhead even when it does nothing. SQLite files cost almost nothing to keep around, which is why per-tenant and per-agent designs have gravitated toward it.
Supabase’s stated plan is a graduated path. Small agent tasks start on a lightweight Turso database, and work that grows into a real application moves onto Supabase’s Postgres platform. SiliconANGLE notes that Supabase also launched Supabase Compute, a hosted sandbox for long-running agents, the same day, which suggests where a Turso instance is likely to sit in practice: next to an agent, holding its working state, until the agent produces something worth promoting.
For developers, the practical shift is that one vendor now wants to own both ends of the data lifecycle for agent-built software, from the throwaway database an agent spins up in seconds to the production Postgres it eventually lands in.
What it means for teams on Turso
If you run Turso in production, nothing breaks this week, and the companies say your databases, APIs, and workflows continue as they are. What has changed is who sets the roadmap. Pricing, plan limits, and the bring-your-own-cloud deployment model that Supabase highlights for Turso customers now answer to a Postgres-first platform. None of those were addressed in the announcements, so they are the details to watch rather than assume.
There is also an open question for embedded users. Turso’s catalog story spans libSQL, its long-running SQLite fork, and the newer Rust rewrite. The announcements commit to keeping “Turso Database” open source but do not address libSQL by name. Teams with libSQL embedded in shipped apps should watch for explicit guidance rather than read the general commitment as covering both.
What it means for teams on Supabase
For Supabase users, the near-term effect is a likely new primitive rather than a change to anything existing. If the integration lands as described, a Supabase project could provision cheap SQLite databases for agents or tenants without adding a second vendor, then promote that data to Postgres when it outgrows the lightweight tier. That is a real simplification for teams currently stitching Turso or Cloudflare D1 next to a Supabase backend by hand.
The consolidation pattern
This follows Databricks folding Electric into Neon in August, another case of a Postgres platform buying the lightweight, embedded end of the data stack to serve agents. The independent database layer for agent workloads is being absorbed into larger platforms quickly. The signal to watch over the next quarter is whether Turso keeps an independent release cadence and pricing, or whether its roadmap narrows to what Supabase’s agent products need. Stackmaven will check back on or around January 3.