Supabase raises $150 million and agrees to acquire Turso

Supabase raised $150 million in a round led by Singapore’s GIC, with CapitalG, IronArc and SquarePeg also participating.[1] Separately, Supabase agreed to acquire Turso for an undisclosed sum.[2] Supabase says the funding will support employee liquidity and the development of AI-agent features.[1] The evidence does not specify how much of the funding will go to either purpose, or give a timeline for the acquisition or the planned feature work.

Turso describes its platform as designed to provide instant, lightweight databases for agents, with a path to Postgres as applications grow.[5] It says its cloud can run millions of databases on one server, loading them when needed and suspending them when idle.[3] Its architecture supports on-demand databases for individual agents in Turso Cloud or customers’ own clouds.[3] Supabase says it wants agents to create databases as easily as files, without needing a dedicated machine for each smaller workload.[3] These statements outline the infrastructure goal; they do not specify a launch date for new Supabase features.

Supabase says existing Turso databases, APIs and workflows will continue as before, and that Turso Database will remain open source and under active development.[5] Supabase also says it will continue building around Postgres while Turso continues its work on SQLite.[3] Turso users will have a path to standard Postgres through Supabase and to petabyte scale with Multigres, according to Supabase.[5] The announcement describes continuity and a migration path, but does not say that users must move their workloads or that every database will automatically migrate.

Supabase says its platform launches more than one million databases per week.[3] Dealroom says the company adds more than one million users and four million databases a month, with agents or AI-driven tools creating 70% of new databases.[4] Supabase says agents are creating millions of databases for prototypes, explorations, dashboards and apps.[3] It describes SQLite as suited to smaller on-demand workloads and Postgres as suited to applications as they scale.[3] These figures and design choices point to a focus on many small workloads alongside applications that grow.