A database per agent: how Turso and Neon give different answers
Neon and Turso both give every agent its own database. On Neon, that is a Postgres project with its own compute. On Turso, it is a lightweight database that costs about as much as a file.
One question comes up in most of my conversations with teams building agent platforms: how do we give every agent, user, or project its own database without the bill and the operations work growing with each one?
Neon and Turso both answer it, and they start from the same observation: agents now create databases far faster than people ever did. They differ on what a single database should be. On Neon, it's a Postgres project with its own compute. On Turso, it's a lightweight database that costs about as much as a file. And since October, Turso is part of Supabase, so a full Postgres platform sits right next to it.
#Agents need many separate databases
Agents have become the main creators of databases. Databricks' 2026 State of AI Agents report found that agents created 80% of new databases and 97% of database branches on Neon by October 2025, up from 0.1% two years earlier. Supabase sees the same pattern: it now adds more than 4 million databases a month, about 70% of them created by agents or AI-driven tools, after reporting a 600% year-over-year increase in databases in June.
We've seen the same trend on Turso. AI companies such as Superhuman, Sauna, CTO.new, and Mastra give each agent its own Turso database, and Sauna alone has created more than 2 million.
An agent needs a database of its own for four reasons:
- No shared schema. An agent that builds an app defines its own tables. A CRM lets each customer add their own fields. With no common schema, there's no single table structure to put everyone's data in.
- Isolation. A bad query or a broken migration stays inside one database. There's no tenant filter to get wrong, and one agent can't read another's data.
- A clean lifecycle. A task starts with a new database and ends by deleting or archiving it. Nothing is left behind in a shared database.
- Data can move with its owner. A per-user database can be synced to that user's device or moved to another region without touching anyone else's data.
Database platforms are adjusting their pricing to match. The first response is to raise the limits. Neon lifted its free plan to 100 projects, offers 1,000 on Scale, and runs an Agent Plan that raises the cap further for platforms it approves. Each project is still a Postgres compute billed by the CU-hour, so a platform still budgets for every database and asks for more as it grows.
Raising limits is a necessary first step, but it carries over the logic of SaaS pricing, where a plan caps seats or projects and a bigger customer buys a bigger tier. That logic doesn’t account for how agents operate: they create a database for each task, and most of those databases go quiet soon after. A cap that made sense per customer turns into a limit on how an agent can work.
The better instinct is to rethink pricing from the primitive up. If a database costs about as much as a file, it can be priced like one: by what it stores and what it reads and writes. That's why every Turso paid plan includes unlimited databases, and why in May 2026 we removed the last limit, on how many could be active in a month (spoiler: unlimited).
An agent can create a database for every task without anyone planning for it. That puts Turso among the companies designing natively for agents, not adapting pricing built for people.
#Neon's answer: a Postgres project per agent
On Neon, each agent or tenant gets a project: a Postgres database on separate compute and storage. The compute autoscales, suspends after 5 minutes of inactivity, and resumes in a few hundred milliseconds when the next query arrives. An idle project costs only its storage.
Neon is also known for branching. A Neon branch is a copy-on-write copy of a project, and since Neon bundles auth, files, and functions into the project, those come along too. Branches are included up to a limit per project, then billed per branch each month.
For fleets, Neon offers 100 projects on its Free and Launch plans and 1,000 on Scale. Platforms that need more can apply for the Agent Plan, which starts from an active Scale plan, needs approval from the Neon team, and raises project limits as usage grows. Compute on that plan costs $0.106 per CU-hour, and storage $0.35 per GB-month.
It's a well-built system, and its unit is clear: every database is a Postgres server with a compute that has to be sized, suspended, resumed, and capped.
#Turso's answer: a database that costs about as much as a file
Turso was designed around the way agents use databases. Agent work comes in short bursts: an agent creates a database for a task, runs a few queries, then waits on a person or a tool, sometimes for hours. It may come back to that database, or never touch it again.
Turso Database is an open-source, SQLite-compatible database written in Rust, and each database is a file. On Turso Cloud, a single server manages millions of these files, loading a database when something queries it and suspending it when nothing does. Creating a database for a new task is as cheap as creating a file. A database the agent stops using costs only its storage, and there's no compute per database to size, cap, or keep running.
For an agent platform, that means:
- Databases are created on demand. The Platform API creates one per agent, user, or tenant, and every paid plan includes unlimited databases.
- Each database owns its schema. An agent defines its tables without a migration touching anyone else's data.
- Isolation comes from the database itself. One tenant's data never shares a table with another's, so there's no row filter to get wrong.
- Branches are databases too. Turso Cloud creates copy-on-write branches, and each branch counts as a database, so branching falls under the same unlimited databases on every paid plan.
Turso Database is available on Turso Cloud and supports concurrent writes with BEGIN CONCURRENT, so several agents or users can write to the same database at once. The 0.8 release made those writes much faster: with group commit, it reached about 9,500 write transactions per second at 64 connections, around 7x SQLite in the same benchmark.
The same core can speak more than SQLite. In July, we started building Postgres in Rust on the Turso engine, compiling Postgres SQL down to the same bytecode. The goal is a Postgres-compatible database that can also be a single file, run embedded, and sync to a local copy. It’s an early foundation, and that work now continues as part of Supabase’s roadmap.
#Where the difference shows up
The two models look similar on a free plan. They separate once a platform runs thousands of databases that wake up for a few queries and go quiet again.
| Neon | Turso | |
|---|---|---|
| One agent's database | A Postgres project with its own compute | A Turso Cloud database on a shared server |
| When idle | Compute suspends after 5 minutes | Database is suspended until the next query |
| Databases on a free plan | 100 projects | 100 databases |
| Databases on paid plans | 100 (Launch), 1,000 (Scale), more through the Agent Plan after approval | Unlimited from the Developer plan, $5.99/month |
| What's metered | Compute (CU-hours), storage, network transfer | Rows read, rows written, storage, syncs |
| Data on the device | Live query results through Neon Realtime (beta); no synced local database yet | Turso Sync keeps a local database on the device in sync with Turso Cloud |
| Where databases run | Neon's cloud, with private networking on Scale | Turso Cloud, or your own AWS or GCP account with BYOC (Enterprise) |
| Customer-managed encryption keys | Not available yet; on Neon's roadmap | A key per database, on the Pro and Enterprise plans |
#Brief activity, billed by what it touched
Agent workloads are bursty: an agent runs a few queries, then waits for a person or another tool. On Neon, each burst starts the project's compute, which keeps running and billing CU-hours until the idle timeout passes. On Turso Cloud, the same burst bills the rows it read and wrote. There's no compute clock per database, so a million databases that each run a handful of queries a day cost what those queries touched, plus storage.
#No approval step for more databases
On Turso Cloud, the Developer plan already includes unlimited databases. A platform can go from its first hundred agents to its first hundred thousand without changing plans or applying for a program. Branches and point-in-time restores each count as a database and use storage, so they follow the same rules.
#A database on the device, not only results
Turso Database can run inside the app itself: in the same process on a server, in the browser, or on a phone. With Turso Sync, the app reads and writes that local database, then pushes and pulls changes with Turso Cloud, so an agent or app keeps working when it's offline. Turso Sync runs in production today. Sauna, for example, keeps each user's connected inbox and calendar in its own Turso database, synced through Turso Sync.
Neon approaches sync from the cloud side. Its sync is built around Neon Postgres in the cloud, and Neon Realtime keeps the results of live queries up to date in the client. Turso starts from the other end: the database itself runs where the app runs, and Turso Cloud is where it syncs to.
#Per-agent databases in your own cloud account
Many agent platforms sell to enterprises that want agent data to stay in their own cloud account. That gets harder when every agent has its own database: a server per database multiplies the infrastructure you'd have to run there. With Turso Cloud BYOC, the same file-per-database model runs in your AWS or GCP account, so a customer's agents get their own databases without a fleet of servers to manage.
#An encryption key for each database
Turso Cloud supports bring-your-own-key encryption (BYOK), and keys are set per database. A platform can encrypt each customer's agent databases with that customer's own key, so that data stays protected by keys only the customer controls. Neon doesn't support customer-managed keys today.
#Turso now comes with a Postgres platform
For many teams, Neon's advantage was having one vendor for everything, including the Postgres database behind the main app. Since Turso joined Supabase in October, picking Turso for per-agent databases also puts a full Postgres platform in the same company.
- The app's main backend can run on Supabase Postgres, with auth, storage, functions, and realtime, while each agent or tenant gets a Turso database.
- Workloads have somewhere to grow. Supabase describes a clear path from Turso into the broader Supabase ecosystem as workloads grow.
At Supabase Select, Supabase also introduced Spark, a new instance type built on Turso's technology, for scaling out to very large numbers of databases. Turso Cloud stays the home for SQLite workloads, and Turso Database stays open source.
#When you need Postgres instead
Turso isn't the right database for every part of an agent platform. In most of those cases, I'd point a team to Supabase:
- The database needs Postgres. If your agents rely on Postgres extensions or Postgres-specific SQL, a Turso database speaks SQLite's dialect. Supabase Postgres covers those parts of the app.
- Storage dominates the bill. For a large database that's rarely queried, Supabase's disk pricing is lower: 8 GB per project included on paid plans, then $0.125 per GB-month. Turso's paid plans include 9 GB to 50 GB, then charge $0.45 to $0.75 per GB.
One case still favors Neon: agents that each need a copy of a single production app, with its data, auth users, and files. Neon branches the whole backend in under a second, and that's what it's built for.
If your agents or users each define their own small database, Turso fits better, and Supabase Postgres is there for everything that needs Postgres.
#Getting started
Turso Cloud's free plan includes 100 databases and 5 GB of storage, with no credit card needed. Create a database per agent through the Platform API, and keep your app's backend on Supabase. Turso Database is open source on GitHub if you want to run it locally first.