On October 2, 2026, at its Select conference, Supabase put three announcements on the table at once: a $150 million round led by GIC (announced by Supabase itself, per its official release), an agreement to acquire Turso, and Supabase Compute, a new layer for running long-lived services right beside your database. The thread tying them together is a single bet: AI agents, not human developers, are becoming the database's dominant customer. Supabase says it already launches more than one million databases every week, with agents behind most of the new ones - both company-reported figures. That volume breaks the old economics of databases, and nearly everything announced this week is a response to it. Here is what each piece is, why they fit together, and what to do about it.
In short:
- Supabase has agreed to acquire Turso, an open-source, SQLite-compatible database engine rewritten in Rust. No source discloses the price or the closing terms.
- Supabase Compute, announced the same day, runs long-lived services and agents next to Postgres. It is in private alpha behind a waitlist, not ready for production.
- Select 2026 also shipped Declarative Schemas 2.0 with pg-delta, config-in-code, agent-ready local development without Docker, and a per-app MCP server.
- The thesis behind all of it: agents should be able to create a database as easily as code creates a file.
What exactly did Supabase announce on October 2?
Three things landed together, and they read best as one package.
The funding. Supabase announced the $150 million round itself, led by GIC with CapitalG, IronArc, and SquarePeg also participating, landing four months after the company's $500 million Series F at a $10 billion pre-money valuation. Per that release, the round includes employee liquidity, with proceeds earmarked for new AI agent features. Press follow-ups add independent technical color on the deal.
The acquisition. Turso is joining Supabase. The price is undisclosed in every source, and no one has stated when the deal is expected to close. Glauber Costa and Pekka Enberg plus the rest of the Turso team come aboard, with Glauber leading a new agentic infrastructure effort at Supabase. For existing users the message is continuity: Supabase continues around Postgres, Turso continues on SQLite, and the combined team builds something new that brings the Supabase experience to every agent.
The products. All announced the same day at Select: Supabase Compute (private alpha), Declarative Schemas 2.0 with the pg-delta migration engine, config-in-code for project settings, an agent-ready local development stack that runs without Docker, and a per-app MCP server you can add with a single shadcn command.
Why does Supabase think agents are the database customer now?
Because the shape of demand has changed, not just its size. A human developer provisions a database rarely; it is a commitment you own for years. An agent behaves differently: it spins up a database for a prototype, one for an exploration, one for a throwaway dashboard, one as a scratch store for a single task, and then it abandons them. Supabase's acquisition post puts it plainly: agents are spinning up millions of databases for the prototypes, explorations, dashboards, and apps they build.
The numbers trail that shift, and the attribution matters. In Supabase's own words, database launches grew 600 percent in the year to June 2026, and more than 60 percent of new databases were launched by some sort of AI tool as of that June - both company-reported from the Series F post. By October, press reports citing the company put the agent share at 70 percent of new databases, while Supabase's own acquisition post says the company is "already launching over one million databases per week." Supabase also says growth accelerated since January as Claude Code and Codex expand who can build software at all.
The old cost model does not survive this. Today every small workload implicitly assumes a dedicated, long-running machine, and agents do not care about machines - they want a database now. Supabase's position, verbatim: "Agents should be able to create a database as easily as creating a file, with just as little concern about cost." The company argues this new pattern at this scale requires an evolution in database infrastructure, not an incremental bump.
There is a second, quieter demand pattern: agents as authenticated app users, not just builders. The per-app MCP server means an agent working inside your app generates database workload shaped by the signed-in user's permissions, not admin keys. If you are designing for this world, the way agents hold and use context across steps - our AI agent memory guide covers it - starts to matter as much as schema design.
What is Turso, and why do agents want millions of tiny databases?
Turso is an open-source database engine compatible with SQLite, rewritten in Rust. The key idea is simple: a database is a lightweight file, not a long-running server process demanding its own machine. That design choice is what makes "a database per agent" economically sane.
The architecture, as Supabase's own post describes it, is a load/suspend model: Turso "rebuilt SQLite in Rust and created a cloud platform where a single server can manage millions of databases, loading them when needed and suspending them when they're not." No database hogs memory while nobody uses it; create is cheap, suspend is free. Press coverage of the deal adds technical color - near-instant spin-up, support for embeddings, encryption that differs slightly per database page, and a footprint small enough for smartphones and wearables - press-reported detail, not Supabase's own claims. The embeddings support is the piece agent builders will notice first, since a tiny file-based database that can also store vectors fits neatly into the vector database patterns most retrieval workflows already use.
Why did Supabase want it? Because it is the missing cheap-to-create tier. SQLite suits small, on-demand workloads; Postgres is what you want as an application scales. Today an agent that prototypes on SQLite faces a cliff when the workload grows up and needs Postgres. The bet is one developer experience across both tiers, from throwaway scratch database to production system. And this is not theoretical: Supabase names Superhuman, Sauna.ai, CTO.new, and Mastra as customers already provisioning a database per agent on demand, whether on Turso Cloud or in their own clouds. Press reports also attribute a stated ambition to the company: serving more than a billion databases.
What is Supabase Compute, and how is it different from Edge Functions?
Status first: Supabase Compute is in private alpha, behind a waitlist, and explicitly not for production workloads yet. Expect churn in how services are defined while it matures.
What it is: long-lived services and agents in any language, in the same project as your database. Compute hosts things that should never exit - agents, embeddings jobs over large file sets, always-on services, sandboxed code - with no limit on how long a service runs. You choose memory and CPU, and you get a full Linux environment, which Edge Functions do not offer. Edge Functions stay what they have always been: short-lived request/response handlers, and the production-grade option for that job.
| Supabase Compute (private alpha) | Edge Functions | |
|---|---|---|
| Runtime | Long-lived, no time limit | Short-lived request/response |
| Environment | Full Linux, you pick memory and CPU | Constrained, no full Linux |
| Access | Public HTTP URL, or private with no HTTP at all | HTTP endpoints |
Compute deploys from the Supabase CLI or the Management API, with the service definition in config.toml. Each service gets a public HTTP URL by default, or you can mark it private with no HTTP at all - the right shape for background jobs or an agent sandbox nothing public can reach. You set an instance count and Supabase balances across them, and network restrictions can lock database access down to Compute instances only.
What else shipped for agent workflows at Select?
Beyond Compute, Select 2026 shipped four features that let a coding agent own schema, config, local development, and app-level agent access straight from the repo.
Declarative Schemas 2.0 with pg-delta. The reasoning is disarmingly practical: "coding agents are good at editing schema files and bad at writing migrations." So now the SQL schema files in your repo are the source of truth, and pg-delta, a diff engine, generates the migrations. It is the default for new projects created with supabase init; existing projects opt in through a config.toml flag, and you should review generated migrations before trusting them.
Config in code. Auth providers, API limits, and storage buckets move into config.toml. Two commands keep repo and dashboard honest with each other: supabase config pull brings dashboard changes back into your repo, and supabase pull fetches config, schema, and Edge Functions together.
Agent-ready local development. The new local stack runs as native processes with no Docker daemon required, which means it works inside Claude Code sandboxes, Codex, and CI runners. Each directory or worktree gets its own isolated stack, so an agent can test two changes side by side without collisions. It is alpha and off by default - you enable it with a config.toml flag or an environment variable.
The per-app MCP server. One shadcn command - npx shadcn@latest add @supabase/mcp-server - adds an authenticated MCP endpoint to your app. Users sign in exactly as usual, and row level security still decides which rows the agent can reach: the agent sees what the signed-in user may see. It requires asymmetric signing keys and the Supabase Auth OAuth server, and there is a headless template for apps where the agent is the main interface. If MCP itself is new territory for you, our MCP protocol explainer covers how these endpoints work.
Add it up: schema, config, long-lived services, and app-level agent access are all repo-reviewable artifacts now, and a coding agent can own the whole chain end to end.
What should you adopt now - and what should you wait on?
Adopt the schema-as-code, config-in-code, and per-app MCP pieces now; wait on everything still in alpha.
Adopt now:
- Treat SQL schema files, not hand-written migrations, as the source of truth on new projects. pg-delta is the default there already.
- Move project config into config.toml and use supabase config pull to keep the dashboard from drifting.
- Add the per-app MCP server if users want agent access inside your app, and scope it hard with RLS, plus the signing keys and Auth OAuth server it requires.
- Design agent workloads around many small databases - per user, per agent, per session - instead of one shared database. That is where the platform investment is going.
Wait on:
- Supabase Compute: private alpha, waitlist, config churn likely. Watch it, do not build on it.
- The no-Docker local dev stack: alpha and off by default. Opt in per project only where reproducibility risk is acceptable.
- pg-delta on existing projects: fine to try, but review the generated migrations before you trust them.
- Multigres for scale: v0.1 alpha, explicitly not production-ready. OrioleDB is the nearer bet. The one-sentence takeaway of the whole announcement day: the interesting question is no longer which database agents will use, but how many databases each agent gets.
Frequently asked questions
Does my existing Supabase project change because of this?
No. Nothing announced is forced on existing projects: pg-delta and config-in-code are opt-in via config.toml flags, the new local dev stack is off by default, and Compute is waitlist-only. The new defaults apply to new projects.
What happens to Turso the product and Turso Cloud?
Per the announcement, Turso continues on SQLite while Supabase continues around Postgres, and existing Turso users were told nothing changes. The combined team is building a new experience that brings the Supabase model to every agent. The price and closing terms are undisclosed.
Is Supabase Compute generally available?
No. It is in private alpha with a waitlist and is explicitly not for production workloads yet; expect churn in the config.toml service definition. Edge Functions remain the production-grade option for short-lived handlers.
How much did Supabase pay for Turso?
No source states a price, and closing timing and conditions are also unstated. The company itself announced the $150 million round, on top of the company-confirmed $500 million Series F at a $10 billion pre-money valuation in June 2026.
