Supabase 為何受 AI 智能體青睞

I first met Paul Copplestone and Ant Wilson in Singapore, shortly after they finished YC as the hottest startup of YC S20. Six years later, we finally got them on the podcast! This is their first podcast together, after taking an open-source, fully remote company from zero to a $10 billion valuation.

The title is a question I wanted to understand for myself: why do agents love Supabase? There are plenty of managed databases. Postgres hosting is competitive. Being familiar to a model is useful distribution, but it doesn't explain all the work needed to turn a generated application into something that runs. But when I ran my frontier AEO tracker, it was an almost complete sweep of first choice for app backends (and in contention for managed db) for every frontier model from Astra to Fable to Muse.

At Select, Supabase grouped its announcements into Build, Operate and Scale.

The things that stood out to me were surprisingly practical: start a local backend without Docker, keep the desired database schema in Git, and run compute beside the database. Each removes a piece of work that developers have been doing for years. Agents make that friction harder to ignore.

Watch the full conversation, including my opening commentary →

Give the agent a backend it can read

My favorite developer-tool announcements make me think: of course I want this today. The new alpha runtime for running Supabase locally without Docker is one of those. I use Colima rather than Docker Desktop, and even then, removing another dependency from the path to a working database is welcome. Local setup is a small part of a human developer's week; an agent that repeatedly creates and tests environments encounters it over and over.

Declarative schemas are the bigger idea. The familiar SQL workflow accumulates a history: create the schema, then migrate, migrate, migrate. A declarative representation gives the agent a description of the state you want, in files it can inspect and edit alongside the application.

In the commentary, I compare this to a Terraform moment for the database. Put the desired state in Git and the agent can read it, change it, fork it and work against it as part of the repository. Humans get the same advantage: the backend becomes easier to understand without reconstructing its entire history.

That is the part I like most about the agent-friendly direction. These are improvements I wanted as a developer already. Making them useful to agents gives the team another reason to finish the job.

Compute deserves more than a bullet point

I think Supabase Compute, now in private alpha, may be undersold. An application needs somewhere to do its work as well as somewhere to store the result. Once you have a database, you still need a place to run the processes that chunk documents, generate embeddings or do other longer-running work.

Paul and Ant discuss running containers close to the database. That closes a gap between getting an application started and operating it: fewer separate services to configure, connect and explain to the agent. Edge functions remain useful, but they don't cover every workload.

The operating side matters too. Logs, checks, connections and context help an agent understand what it is changing. A model that can issue SQL still needs to know what the database contains, how the application uses it, and what happened when something failed. Supabase's Operate announcements are worth reading alongside the new ways to build.

From prototype to petabyte

The founders say Supabase is launching about five million databases a month. They are thinking about what happens if agents push that toward billions of applications. At the same time, existing customers are growing into much larger workloads. Serving more small databases and supporting a customer's increasingly large database are different engineering problems.

That helps explain the breadth of the Scale announcements: OrioleDB, Multigres and the Turso acquisition. The conversation gets into the work behind the new “prototype to petabyte” positioning, including Postgres reliability and the choices involved in scaling up and scaling out.

One observation from Paul and Ant is particularly interesting for anyone building developer tools: as AI-driven usage grew, they say activation and conversion improved. Their explanation is that an agent can carry a user from signup to a working setup in one flow. The person doesn't have to figure out every configuration step before seeing the application work.

We also talk about the memes and community that helped Supabase grow, open-source adoption and enterprise sales, and whether agents will converge on the same application patterns. But I wanted this episode to capture the founders' chemistry as well. It is a chance to hear Paul and Ant think through the product together—and to see how much work sits behind a backend that an agent can make look easy.

Show notes

• Supabase Compute — run workloads alongside the database.

• Multigres — the team’s approach to highly available Postgres, currently in private alpha.

• Supabase acquires Turso — the database architecture behind its scale-out ambitions.

• Supabase Select — the event discussed in this conversation.

Chapters

0:00 Welcome and why agents love Supabase
5:23 Paul Copplestone and Ant Wilson
6:39 Compute beside the database
8:05 OrioleDB and Multigres
12:50 Scaling up, scaling out, and Turso
17:53 Developer marketing and memes
23:15 The launch and the migration
31:03 Vectors, growth, and AI recommendations
41:43 Product-led sales and enterprise growth
49:38 Live migrations and analytics
58:43 Agent-ready local development
1:06:43 Community and company workflows