Supabase Bought Turso Because Agents Need a Database Per Task

Supabase announced on October 2 that it raised $150 million and is acquiring Turso, a SQLite-based database company. The round was led by Singapore's GIC, with Alphabet's growth fund CapitalG, IronArc and SquarePeg participating. The acquisition price was not disclosed, and the funding announcement should not be read as the purchase price.

The architectural bet underneath the deal is the interesting part. Supabase built its business around Postgres, a relational system designed for applications that share one coherent store. Turso rewrote SQLite from scratch and removed its single-writer constraint, then delivered it through a diskless architecture with the write-ahead log kept on S3. The result is a database that can be provisioned on demand, per agent, at a fraction of the cost of spinning up a machine for each one.

The numbers Supabase is citing

Supabase says it is now adding more than one million users and roughly four million databases every month. It reports that about 70 percent of new databases on the platform are created by agents or AI-driven tools. In June, it reported a 600 percent year-over-year increase in database count, and said agents were already responsible for most new deployments. The company says more than 13 million developers use the platform.

Those are company-reported adoption figures, and database creation is not the same measurement as revenue or retention. A database that an agent spins up for a task and abandons an hour later still counts in that monthly total. What the numbers do show is the shape of the demand curve: the volume of databases being created is growing faster than the number of humans creating them, which is exactly the signal that a per-application database model is under strain.

Why one database per agent breaks the old arithmetic

The unit of infrastructure is changing. When a human developer builds an application, one database serves many users, and the cost of provisioning it is amortised across a long-lived project. When an agent runs a task, it may need its own scratch store for state, memory or intermediate results, and it may need it for minutes.

Provisioning an instance per agent under a conventional managed database model does not work at that scale. The overhead of allocating a server, configuring it, and billing it dwarfs the value of the small workload running inside it. Turso's pitch is that a database should cost almost nothing to create and almost nothing to keep idle, so that launching a million of them is a normal operation rather than an accounting event.

The customer list Supabase cites for Turso includes Superhuman, CTO.new, Sauna.ai and Mastra. Turso founder Glauber Costa is joining Supabase as Head of Agentic Services, alongside co-founder Pekka Enberg and the rest of the team.

One detail is worth flagging for anyone already using Turso. The company's earlier libSQL fork and its newer Rust engine are different implementations, and the two do not have the same feature set. Turso explained the transition in a January 2025 rewrite announcement. A team should check which engine its deployment runs on before assuming a feature listed on the marketing page is available in production.

The competition this is aimed at

The acquisition also clarifies what Supabase is competing with. Its paid offering includes authentication, storage, edge functions, realtime subscriptions and vector search, which places it against Firebase, MongoDB Atlas and AWS Aurora in the managed backend market rather than against a single database vendor.

Each of those has a different weakness at the agent layer. Firebase ties developers to a document model and Google's cloud. MongoDB Atlas models data flexibly but charges for a cluster rather than for a unit of agent work. Aurora is powerful and expensive at small scale, with provisioning that does not fit a task that lives for minutes.

Turso's contribution is the smallest possible unit of storage. It offers concurrent writes, native vector search and execution in the browser, alongside embedded replication between devices and the cloud. That last capability matters for a class of application that runs partly on a user's machine, where a round trip to a cloud database is the wrong shape for the problem.

The graduation path is the commercial mechanism. A project that starts as one SQLite database and grows into a real application migrates into Postgres, and with it into a paying plan. Supabase's argument is that capturing the project at the moment an agent creates it is cheaper than acquiring the developer later.

The funding history is its own signal

The round lands four months after Supabase closed a $500 million Series F in June 2026, which valued the business at $10.5 billion post-money and was also led by GIC. That round followed a $100 million Series E in October 2025 at a $5 billion valuation. Total capital raised now sits past the $1 billion mark.

Raising again this soon suggests the company wanted either capital or a headline, and the release says part of the round provides liquidity for employees. A secondary component for staff is normal at this stage, and it is worth separating from the operating cash a company actually deploys.

The strategic logic is clearer than the financial one. Supabase wants to be the place a developer or an agent turns first when a project needs a backend. If the earliest version of that project is a tiny SQLite database created by an agent, then owning the moment of creation means owning the relationship before a competitor sees the project at all. From there, Supabase offers a graduation path into standard Postgres when an application outgrows the lightweight tier. Turso keeps running as a platform, and its codebase stays open source.

The consolidation pattern

Supabase is not alone in this move. Restate raised a $20 million Series A led by Singular this month for durable infrastructure that keeps long-running agent workflows from failing mid-task. LlamaIndex shipped a schema-based document extraction tool aimed at agent data pipelines. The theme across these deals is that the plumbing underneath agents is becoming a category, and the parts of it that were previously an afterthought are now funded.

For builders, the practical question is what changes. Existing Supabase users are told they will see no difference, which is the right answer for a platform that now runs two engines under one roof. The more consequential shift is in defaults. If Postgres and SQLite both live in the same ecosystem, choosing between them becomes a decision about workload shape rather than about vendor, and the cheap option becomes available at the moment an agent needs it rather than after a procurement cycle.

What remains open is whether the economics hold. A per-agent database model is only viable if the storage, provisioning and support costs stay below the price a customer will pay, and if enough of those databases grow into paying production workloads. Supabase has bet that the answer is yes, and that the projects worth keeping will start small.