Databases for AI Agents: Supabase With Turso vs Neon vs PlanetScale on Price

Put 1,000 small, mostly idle databases on each vendor's public rate card and the monthly bill ranges from about $36 to about $9,826. That spread is the real story of the database for AI agents market in 2026. The cheapest option is now owned by Supabase, and the most expensive one is also Supabase, which tells you why it bought Turso.

The short answer. If each agent, user or session needs its own database and most of them sit idle, pick a vendor whose idle database costs only storage. Today that means Turso or Neon. Supabase Postgres and PlanetScale price every database as an always-on instance, which suits a few busy databases and punishes thousands of quiet ones.

Why agent workloads break traditional database pricing

A conventional SaaS app runs one large database shared by every customer. You size it for peak load and pay for it around the clock. The bill grows with traffic, not with the number of customers.

Agent products invert that shape. A coding agent may spin up a database for each generated app. A research agent may want scratch storage per task. A multi-tenant agent platform may isolate each end user so one prompt injection cannot read another customer's rows.

The result is many small, disposable databases with long idle stretches between bursts of work. Most are created by code, not by a person clicking a console. Databricks put a number on this when it announced the Neon deal: over 80% of databases on Neon were created automatically by AI agents, according to internal telemetry.

That shift changes which line on the rate card matters. When you run one database, compute price per hour dominates. When you run 10,000, the cost of a database doing nothing dominates, because that is what most of them are doing at any given moment.

The four numbers that actually decide the bill

Read every vendor's pricing page for four things. First, what an idle database costs. Second, how many databases or projects a plan allows before you need a sales call. Third, how branches are billed. Fourth, how long a sleeping database takes to answer its first query.

Headline plan prices tell you almost nothing on their own. A $25 plan that charges $10 a month for every extra database is more expensive at scale than a usage plan with no minimum. The same logic shows up in how free tiers meter compute across AI products, and it applies with more force to infrastructure.

All figures from each vendor's own pricing page or documentation, US list prices. A CU is Neon's compute unit, roughly 4 GB of RAM with matching CPU. PlanetScale prices are for us-east-1 and exclude storage, backups and egress, which the pricing page lists as separate components.

Supabase with Turso: two price models under one roof

On 2 October 2026 Supabase announced $150 million in new funding led by GIC and the acquisition of Turso, the SQLite-based database company. Turso's CEO Glauber Costa joins Supabase as Head of Agentic Services, alongside cofounder Pekka Enberg and the rest of the team.

The deal is easier to understand once you put the two rate cards side by side. They describe opposite economics, and Supabase now owns both.

Supabase Postgres prices every project as an instance

Supabase Pro starts at $25 a month and includes $10 of compute credits, enough for one project on the Micro size. Every additional project runs its own compute, billed at $0.01344 an hour, about $10 a month. Paid projects are never paused for inactivity.

That is a sensible model for the product Supabase was built to be: a full backend with auth, storage and a Postgres database per app. It is a poor model for an agent that wants a database per user. At 1,000 projects you pay for roughly 730,000 Micro hours a month whether or not anyone queries them.

Turso prices a database like a file

Turso's pricing page says it plainly: idle databases cost only storage, and creating one costs almost nothing. The $4.99 Developer plan includes unlimited databases, 9 GB of storage and 25 million rows written each month, with overage at $0.75 per GB and $1 per million writes.

Turso also says point-in-time restore and branching add no usage cost. For a fleet of agent scratch databases, that is the closest thing on the market to a zero marginal cost per database.

My view: Supabase bought the economics it could not build on its own Postgres stack without cannibalising its core plan. The open question is the graduation path. Supabase's release promises a route from Turso into the wider Supabase ecosystem, and neither company has published what that route costs. If you build on Turso today, get your current terms confirmed in writing, because no pricing commitment appears in either announcement.

Neon under Databricks: scale to zero and the Agent Plan

Databricks announced its intent to acquire Neon on 14 May 2025. Neon's pricing page now describes the product as a set of backend primitives built around Lakebase Postgres from Databricks, and higher-volume customers are offered support aligned with Databricks Support.

The rate card itself still reads like a developer product. There is a free plan, and the two paid plans have no monthly minimum. You pay for compute in CU-hours and storage in GB-months.

Scale to zero is the feature agent builders are buying

A Neon compute suspends after 5 minutes without queries on the Free plan. On paid plans the timeout can be disabled or, on Scale, set from 1 minute to always on. The documentation says a suspended compute reactivates within a few hundred milliseconds on the next query.

The catch is a plan limit, not a price. Launch allows 100 projects and Scale allows 1,000 as a soft limit. If your agents create one project each, you hit the Launch ceiling at your hundredth customer.

The Agent Plan is the real offer, and it is unpriced in public

Neon's plans documentation describes an Agent Plan for AI agent platforms that provision thousands of databases. It offers unlimited projects, compute at the Launch rate of $0.106 per CU-hour, and credits to fund your own free tier. You apply for it rather than buy it.

That matters more than any line on the public card. The two biggest agent app builders do not pay list price, and neither will you once you have volume. I would treat Neon's public Scale price as the ceiling and the Agent Plan as the number to negotiate toward.

PlanetScale: always-on Postgres nodes from $5

PlanetScale took a different route. In a post dated 30 October 2025, it introduced a single-node, non-HA Postgres node type, the PS-5, at $5 a month. The current pricing page lists the PS-5 at $5 single node and $15 as a 3-node HA cluster in us-east-1.

That is a real floor. It is also a floor per database, every hour of the month. None of the PlanetScale pages we read describes suspending an idle database, so a fleet of 1,000 PS-5 nodes costs $5,000 a month before storage and egress.

Always-on means no cold start. If your agent product has a modest number of busy tenants and latency is part of what you sell, paying a fixed $5 to $15 per database buys predictable first-query performance. Neon and Turso can only promise that by turning their idle savings off.

PlanetScale also publishes its pricing data as a queryable SQL catalog with rules written for agents. That is a small thing, and it is the only vendor of the three that treats an agent as a buyer rather than only as a workload.

Database for AI agents cost at 1,000 instances

Rate cards are hard to compare in the abstract, so here is one workload priced four ways. It is a model built from public list prices, not a measured bill, and every assumption is stated so you can change it.

The workload is 1,000 databases, one per end user. Each holds 50 MB, so the fleet stores 50 GB. Each is active for 4 hours a month at 1 CU of compute and idle the rest. Reads and writes stay inside each plan's included allowance. A month is 730 hours.

Illustrative model, not a quote. The Neon Agent Plan row assumes the Launch compute rate described in Neon's documentation and is only available by application. PlanetScale's storage price was not on the pages we read, so that row is a floor.

Change one assumption and the ranking moves

Raise active time from 4 hours to all 730 and Neon stops being cheap. At 1 CU on Scale, a single always-busy database costs about $162 a month in compute alone, far above a $10 Supabase Micro or a $5 PlanetScale node. Those smaller instances are also smaller machines, so the comparison is not like for like.

That is the whole decision in one sentence. Usage-priced vendors win when databases are many and quiet, and instance-priced vendors win when they are few and busy. Know which one your product is before you pick, and model it the way we did for vector database costs at three scales.

Branching for agents: what each vendor actually bills

Branching means creating a copy of a database, usually copy-on-write, so an agent can try a schema change or a risky migration without touching production. It is the second pattern agent builders ask for, after per-agent databases.

The vendors bill branches in four different ways, and the differences are larger than the plan prices suggest.

Neon branches are cheaper than Neon projects for a few, dearer for many

One tempting design is to use a single Neon project and give each agent a branch instead of a project. That sidesteps the 100-project ceiling on Launch. It does not save money at volume: 990 extra branches at $1.50 each adds about $1,485 a month before compute, more than the whole Scale model above.

Branches are the right tool for short-lived experiments that get deleted. They are the wrong tool for durable per-user isolation, and the price card says so if you read it closely. The same trap shows up in enterprise agent cost models that price the pilot and forget the steady state.

Cold starts and limits, from the vendor docs

Per-agent databases fail in production for boring reasons: an unknown quota, or a first query that times out after a database went to sleep. Both are documented, if you look.

The limits that stop you before the price does

Neon's ceilings are the most explicit. Free and Launch allow 100 projects, Scale allows 1,000 as a soft limit, and branches cap at 5,000 per project on paid plans. Neon's documentation also states that computes larger than 16 CU remain always active, so large databases never scale to zero.

Supabase's Free plan allows 2 active projects and pauses them after a week of inactivity. Paid plans never pause, which is the reason idle projects keep costing money. PlanetScale caps development branches at 100 per database by default, adjustable up to 5,000. Turso's Free plan includes 100 databases, and every paid plan is unlimited.

Cold-start claims are vendor wording, not benchmarks

Neon says a suspended compute wakes within a few hundred milliseconds. Turso publishes no cold-start figure, and its file-based design means there is no compute instance to resume in the same sense. Supabase and PlanetScale avoid the question by staying on.

None of these is an independent measurement. If your agent makes a user wait on the first query of a session, run your own test from the region you deploy in before you commit. Waking a database is the kind of latency that never shows up in a demo and always shows up in support tickets, a pattern covered in why agent pilots fail in production.

Where this comparison is weakest

This post compares rate cards, and rate cards are not bills. Four limits deserve stating plainly.

First, the 1,000-database model rests on one workload I chose. Change active hours, data size or write volume and the ranking can flip, as the section above shows. A busy workload favours PlanetScale and Supabase, and I have not modelled every shape.

Second, Turso is not Postgres. It is SQLite with a network layer. If your agent generates Postgres-specific SQL, uses extensions such as pgvector, or must hand a database to a customer who expects Postgres, the cheapest bar in the chart may not be an option at all. Comparing it on price alone flatters it.

Third, the agent-share figures in the stat strip are company telemetry. Neither Databricks nor Supabase disclosed a sample, a window, or what counts as created by an agent. They are directional, and both were published by companies with a reason to tell this story.

Fourth, two of the three vendors changed owners recently, and prices tend to move after acquisitions. Neon's Agent Plan rate is not public beyond its description, and Supabase has not published what Turso customers will pay after integration. Everything here was read on 18 October 2026 and should be rechecked before you sign.

The competing view also deserves credit. Plenty of teams argue that per-agent databases are overkill and that one Postgres with row-level security is simpler and cheaper. For many products that is right, and the isolation trade-offs are similar to those in deciding when to build agent infrastructure yourself.

Frequently asked questions

How to choose this week

Pull one week of your own usage and answer a single question: what share of your databases did any work in a typical hour? If the answer is under 10%, you are paying for idle time on an instance-priced vendor and should price Neon or Turso against it.

Then email the vendor you are leaning toward and ask for three things in writing. First, the per-database rate at your projected count. Second, the project or database ceiling on your plan. Third, their measured cold-start time in your region. If you are on Turso, add a fourth: what your price becomes when it graduates into Supabase. The answers will settle more than this table can. They also tell you how the vendor treats a customer before you are locked in, a risk weighed in the cost of switching AI providers.

Related reading