Agents Create 70% of Supabase's New Databases. Who Is the Customer?

Supabase says 70% of its new databases are now created by agents or AI-driven tools. It said so on 2 October 2026, the day it announced $150 million in new funding and the Turso acquisition. The number is real company telemetry, but Supabase has never defined what an agent is, and its own share figure has changed denominator three times in a year. The agent opens the database. A human, or a platform, still pays for it.

The short answer. When an agent creates a database, the customer is still whoever owns the organisation it lands in. On Supabase that is the developer who connected the tool, or the builder platform that owns the project until a user claims it. The agent is a provisioning channel, not a buyer. What changes is the timing: the human now shows up after the database exists.

What Supabase claimed about agent databases, and when

Start with the exact words, because the argument depends on them. The October release says Supabase is "adding more than 1M users and 4M databases per month with 70% of new databases created by agents or AI-driven tools". That is the source of the headline figure, and it is the only place the 70% appears in Supabase's own material.

Four months earlier, the Series F post by CEO Paul Copplestone made a related but different claim. It said database launches had grown 600% in the past year and that "more than 60% of new databases are launched by some sort of AI tool". The post is dated 4 June 2026 and announced a $500 million Series F at a $10 billion pre-money valuation, led by GIC.

A year before that, the number was framed around people. Fortune reported in October 2025 that "AI builders," as Copplestone termed them, tended to represent about 30% of signups. That is a share of humans joining, not a share of databases created.

Wording quoted from Fortune (3 October 2025), the Supabase Series F blog post (4 June 2026) and the Supabase funding release (2 October 2026). Supabase has not published a definition for any of the three categories.

Read top to bottom, the table tells a growth story. Read across, it tells a measurement story. The unit moved from people to launches to creations, and the actor moved from a type of developer to a type of software. Those are not the same series, and charting them as one trend line overstates how much has changed.

Testing the 70% agent databases figure against Supabase's own definitions

The fair test is not whether 70% is true. Nobody outside Supabase can check that. The fair test is whether the claim is specified well enough that it could be checked, and whether the company's other figures are consistent with it.

What "agents or AI-driven tools" leaves undefined

Three readings fit the phrase, and they describe very different businesses. In the first, a developer types a request into Claude Code or Codex and the tool calls the Supabase API on their behalf. The human is present, chose Supabase and owns the account. Calling that an agent customer is a stretch.

In the second, a builder platform such as Lovable or Bolt provisions a backend for a user who described an app in plain language. The user may never have heard of Supabase. Fortune and TechCrunch both named Lovable and Bolt as Supabase customers in October 2025.

In the third, an autonomous agent creates a database mid-task, with no human request for that specific resource. This is the case the Turso deal is built for. Copplestone's acquisition post says agents are spinning up millions of databases "to power the prototypes, explorations, dashboards, and apps they're building". Supabase does not say how the 70% splits across these three.

My read is that the first two readings make up most of the 70%, because those are the integrations Supabase documents publicly. That is an inference, not a disclosed fact, and it matters. If most agent-created databases have a human one click away, the customer relationship has barely moved.

Do the other numbers hold together?

Mostly, with two loose ends. The release says 4 million databases a month. The acquisition post says over one million databases per week. Those agree within rounding, and 70% of 4 million implies roughly 2.8 million agent-created databases a month.

The loose ends are the time windows and the developer counts. The June post said the 600% growth happened "in the past year". The October release says the 600% was "reported in June" and adds that "agents were already deploying the majority of new databases" then, which is a stronger phrasing than June's "some sort of AI tool". Developer counts went from 4 million in October 2025, to "nearly 10 million" in June, to "more than 13 million" in the October boilerplate. Each figure may be correct. None comes with a definition of an active developer.

Why the Supabase Turso acquisition follows from the 70% claim

Turso's founder framed the deal as a unit-economics problem. In Turso's announcement, Glauber Costa wrote: "One agent, one task, one user. Each agent deserves its own isolated database and the economics have to work at millions of databases." He joins Supabase as Head of Agentic Services, alongside cofounder Pekka Enberg.

That sentence is the strategic logic in one line. Supabase's core product gives every project a dedicated Postgres instance. Its billing documentation says you are charged for that server's compute "independent of your database usage". A pricing model built for apps that run all month fits poorly with databases that live for one task.

The graduation path is the commercial bet

Turso is SQLite, not Postgres. Costa's post describes the intended route: "When SQLite isn't enough, you can move into standard Postgres through the Supabase ecosystem." That is a funnel. Agents create cheap disposable databases, a fraction of them become real apps, and those graduate into Supabase's paid Postgres.

I think this is the smartest part of the deal and also the least proven. Nobody has published a conversion rate from agent scratch database to paid project, at Supabase or anywhere else. The cost side of that funnel is already priced in our comparison of database for AI agents rate cards, so this post does not repeat it.

Who is the customer when an AI agent opens the database?

Supabase's own documentation answers this more clearly than its press release. It describes two ways for software to create projects, and Neon has added a third pattern worth naming. In every case a human or a company still holds the bill. What differs is when they arrive and whether they ever learn the vendor's name.

Model one: the agent acts inside the user's own account

Supabase's OAuth integration guide lets a third party "manage users' organizations and projects on their behalf". The tool receives tokens granting full access to the Management API for that user. A project created this way lands in an organisation the user already owns.

Here the customer is unambiguous. The developer signed up, picked a plan and authorised the tool. Supabase billing is per organisation, so the agent spends the human's money and the human sees the invoice. This is the closest thing to the old model, with software doing the clicking.

Model two: the platform owns the projects

The Supabase for Platforms guide covers the opposite case, where projects sit "in a Supabase organization that you own". It says plainly that Supabase "is commonly used as a platform by AI Builders and frameworks needing a backend". In this model Supabase's customer is the platform, and the end user is the platform's customer.

The same guide includes a claim flow. A user can take over a project that lives in the platform's organisation, with the platform keeping access through OAuth. So one database can change customer partway through its life, from platform to end user, without being recreated.

Model three: the database exists before any account does

Neon has gone furthest. Its claimable databases let "agents provision a Neon project before a human creates an account", with "no account or payment details required". Unclaimed projects expire after 72 hours and are capped at 100 MB of storage and 1 GB of transfer.

Neon's agent documentation adds a rule that makes the point better than any analyst could: "An agent must not complete the claim." Only a human can accept the transfer into an organisation. Even the most agent-first database product on the market requires a person to become the customer.

From Supabase's OAuth integration and Supabase for Platforms documentation and Neon's claimable database pages, read 20 October 2026. Neither Supabase guide states billing terms for platform-owned projects; the payer column follows Supabase's per-organisation billing rule.

The pattern across all three rows is the same. The agent is the account opener, and the account owner is always a legal entity with a card on file. If you sell developer infrastructure, your customer did not change. Your top of funnel did, and the human now meets your product after it is already running their code. That has the same identity problems we covered in how non-human identities get access, now applied to procurement.

Is SaaS dead for developer tools? The seat question

The popular version of this story says that when agents open accounts, seat-based SaaS loses its unit of sale. That is true for some software. It is not true for Supabase, and the distinction is the most useful thing in this post.

Supabase's pricing page lists team members as "Unlimited" on all four plans. It says Supabase "uses organization-based billing" and that each project "runs its own compute instance". Pro starts at $25 a month, Team at $599 and Enterprise is custom. There is no line on the invoice that counts people.

The unit of sale that survives automation

A vendor whose meter counts projects, compute hours or storage gains volume when agents arrive. Every agent-created project is a potential billable unit, so 2.8 million agent databases a month is a demand signal, not a threat. This is why database vendors are buying agent infrastructure while seat-priced vendors are rewriting price books.

The vendors that should worry are the ones whose meter counts humans. If an agent does the work a developer did, a per-developer price shrinks with it. We traced that mechanism in seat compression in SaaS pricing, and the same logic sorts which value metrics survive automation. Developer infrastructure mostly picked a surviving metric years ago.

So my answer to "is SaaS dead" here is no, with a narrower claim attached. Seat-priced SaaS is under pressure. Usage-priced infrastructure is getting more customers than it can bill well, because many of them are machines on a free tier.

What agent databases mean for developer infrastructure pricing

The pricing problem is not the unit of sale. It is the free tier. Supabase's Free plan allows 2 active projects and pauses them after a week of inactivity. Neon caps unclaimed databases at 100 MB and deletes them after 72 hours. Both rules exist because the cost of a database nobody pays for is real.

When humans created the databases, the free tier was a marketing budget aimed at developers who might one day pay. When agents create them, the free tier becomes a compute subsidy for other companies' products. A builder platform that spins up a backend for every visitor is effectively running on the vendor's acquisition budget. That is the same dynamic we described in how free tiers meter compute, one layer down the stack.

Price the account, not the actor

The tempting response is to charge agents differently from humans. I think that is a mistake. Agent detection is unreliable, and the three models above show the same database can be agent-created and human-owned at once. Pricing on the actor invites both gaming and false positives.

The better lever is what Neon and Supabase have already started building: price ownership. Make unowned resources cheap, short-lived and capped. Make claiming them the moment a human picks a plan. Then the question of who created the database stops mattering, because the meter starts when someone takes responsibility for it. Selling to agent-originated users raises the same issues covered in product-led growth when agents are the users.

There is one more implication for buyers. If your team builds on a platform that owns your backend through a platforms programme, you are not Supabase's customer. You are the platform's customer, on the platform's terms, with a claim flow as your exit. Read that flow before you ship anything you cannot afford to lose.

Where this argument is weakest

Four things cut against the case I have made, and two of them are serious.

First, I have criticised Supabase for not defining "agent", and then made my own inference about how the 70% splits across three models. That inference rests on what Supabase documents publicly, not on its telemetry. If most of the 70% is truly autonomous agents with no human in reach, the customer relationship has shifted further than I argue.

Second, the shifting denominators may be honest. A company's metrics often get sharper as a trend becomes important enough to instrument. Moving from signups to databases could reflect better measurement rather than a better story. I cannot tell which from the outside, and neither can you.

Third, the Sacra figures in the chart above are estimates from a partly paywalled note that does not state its method. Its own numbers do not reconcile: it gives $170 million in annual recurring revenue for May 2026 against about $101 million at the end of 2025, and calls that growth of about 221%, which those two figures do not produce. I used it only for the shape of the funnel, not for any revenue claim.

Fourth, the seat argument is narrower than it looks. Supabase has no seats, but plenty of developer tools do, and agents creating accounts on those tools could hurt them in exactly the way the popular story says. My claim is about metered infrastructure, not about all of SaaS.

The competing view deserves credit too. Databricks made the same claim before Supabase did, citing internal telemetry that over 80% of databases on Neon were created automatically by AI agents rather than by humans in May 2025. Two acquirers with independent data reaching similar figures is weak corroboration. It is still corroboration.

Frequently asked questions

Where to start if agents are opening your accounts

Pull last month's new accounts or projects and tag each one by how it was created: dashboard, your API with a human session, a partner integration, or a token with no human login. You cannot price or forecast a channel you are not measuring, and this tag is the definition Supabase has not published. Writing your own down puts you ahead of the press release.

Then check your price meter against that split. If the meter counts people and the fastest-growing channel has no people in it, start the repricing conversation this quarter rather than at renewal. If the meter counts usage, look at what unowned resources cost you, and decide what a claim moment looks like in your product.

Related reading