为什么 AI Agent 偏爱 Supabase?创始人详解构建面向智能体的后端生态
英文标题:Why Agents Love Supabase
Supabase 创始人 Paul Copplestone 与 Ant Wilson 首次合体做客 Latent Space 播客,探讨公司如何从零成长为估值 100 亿美元的开源独角兽。在近期前沿模型评测中,Supabase 横扫各大模型,成为 AI Agent 构建应用后端的首选;平台每月创建约 500 万个数据库,并借由 OrioleDB、Multigres 及收购 Turso 推进“从原型到 PB 级”扩展。面对 Agent 时代,Supabase 通过无需 Docker 的本地开发、声明式 Schema 以及贴近数据库的容器计算,大幅消减开发与运维摩擦,其经验表明 AI 智能体正直接助力开发者工具的激活与转化。
6.5 KB
10.7 KB
6.7 KB
13.6 KB
101.5 KB
15.9 KB
8.3 KB
10.2 KB
8.7 KB
3.3 KB
5.1 KB
11.5 KB
7.0 KB
28.4 KB
6.9 KB
25.6 KB
130.5 KB
中文
为什么 AI Agent 偏爱 Supabase
Paul Copplestone 与 Ant Wilson 谈构建面向 AI Agent 的后端平台
收听本期对话(77 分钟)
我第一次见到 Paul Copplestone 和 Ant Wilson 是在新加坡,当时他们刚作为 YC S20 最热门的创业公司 毕业不久。六年后,我们终于把他们请到了播客中!这是他们首次共同参与播客录制——此时他们已经带领这家开源、完全远程办公的公司从零起步,成长为估值百亿美元的独角兽。
本期节目的标题也是我一直想探寻的问题:为什么 Agent 如此偏爱 Supabase? 如今市面上有大量的托管数据库,Postgres 托管领域的竞争也异常激烈。被大模型熟悉确实是一种有效的分发优势,但这不足以解释将生成的应用真正落地运行所需的全部底层工程。然而,当我运行前沿 AEO 追踪器时,在从 Astra、Fable 到 Muse 的所有前沿模型中,Supabase 几乎横扫了应用集成后端首选的宝座(同时在托管数据库竞争中名列前茅)。
在近期举办的 Select 大会上,Supabase 将其重磅发布归类为三部分:构建(Build)、运维(Operate)与扩展(Scale)。
其中最触动我的特性极其务实:无需 Docker 即可启动本地后端、在 Git 中保存数据库目标状态(Schema),以及直接在数据库旁运行算力。每一项都消除了开发者多年来不得不忍受的繁琐工作,而 Agent 的出现,让这些工程摩擦变得更加无法忽视。
给 Agent 一个它读得懂的后端
最棒的开发者工具更新总会让我感叹:为什么我今天才用上?无需 Docker 即可在本地运行 Supabase 的全新 Alpha 运行时便是其中之一。我自己习惯用 Colima 而非 Docker Desktop,即便如此,能从通往可用数据库的链路中减掉一个依赖项依然大受欢迎。本地环境配置对人类开发者来说可能只占每周的一小部分时间;但对于反复创建和测试环境的 Agent 来说,这种摩擦会成百上千次地重复出现。
声明式 Schema 则是更具深远意义的构想。常见的 SQL 工作流会不断堆叠历史记录:创建 Schema,然后陷入一次又一次的 migrate。声明式表示法为 Agent 提供了一份明确的目标状态描述,这些文件可以与应用程序代码放在一起接受审查与修改。
在分析中,我将其比作数据库领域的“Terraform 时刻”。把目标状态提交到 Git 中,Agent 就能直接读取、修改、分支并在同一仓库内基于它协同开发。人类开发者同样受益匪浅:无需重新还原整套历史变更,后端架构就一目了然。
这正是我最看好 Agent 友好化方向的原因。这些改进本就是我们作为开发者长期梦寐以求的;而让它们适配 Agent,又为团队彻底攻坚并交付这些功能提供了充分的理由。
计算能力不应只是个注脚
我认为目前处于内测 Alpha 阶段的 Supabase Compute 价值被低估了。一个应用程序不仅需要存储运行结果的场所,还需要执行计算的地方。拥有数据库之后,你依然需要算力来运行文档分块、生成 Embedding 向量或执行长时间运行的后台任务。
Paul 与 Ant 探讨了在数据库近端运行容器的方案。这弥合了“启动应用”与“正式运维”之间的鸿沟:无需额外配置、连接并向 Agent 解释多个分散的独立服务。Edge Functions 依然不可或缺,但无法涵盖所有计算负载。
运维侧同样关键。日志、健康检查、连接管理与上下文信息,能帮助 Agent 确切理解它所修改的内容。即使模型能够生成 SQL,它依然需要掌握数据库内存储了什么、应用如何消费它,以及故障发生时的详细诊断上下文。Supabase 发布的 Operate 系列更新 与全新的构建方式同样值得深入研读。
从原型到 PB 级扩展
两位创始人透露,Supabase 目前每月启动约 500 万个数据库实例。他们已经在思考,如果未来 Agent 将这一规模推向数十亿个应用会发生什么。与此同时,现有企业客户正在向海量数据负载演进。服务大量微型数据库与支撑单一客户日益庞大的数据库,完全是两门截然不同的工程学问。
这也解释了 Scale 系列更新 的广度:OrioleDB、Multigres 以及对 Turso 的收购。对话深入剖析了全新“从原型到 PB 级(prototype to petabyte)”定位背后的技术探索,涵盖 Postgres 可靠性保障,以及纵向扩容(Scale up)与横向扩展(Scale out)之间的架构权衡。
Paul 和 Ant 的一个洞察对于所有开发者工具团队都极具启发:随着 AI 驱动的使用场景激增,产品的激活率和转化率反而显著提升。他们的解释是,Agent 可以引导用户在单一闭环工作流中从注册直接抵达可用系统,用户无需在看到应用真正跑通之前死磕每一个繁杂的配置环节。
我们还探讨了助力 Supabase 崛起的 Meme 文化与开发者社区、开源采纳与企业级销售策略,以及 Agent 是否会最终收敛到统一的应用范式。这期节目充分展现了两位创始人的合作默契,让听众得以跟随他们深入思考产品形态——并见证在一个能让 Agent 举重若轻的后端背后,到底承载了多么庞大的工程支撑。
节目提要
章节时间戳
0:00 开场与为什么 Agent 偏爱 Supabase
5:23 创始人 Paul Copplestone 与 Ant Wilson 登场
6:39 数据库就近计算(Compute beside the database)
8:05 OrioleDB 与 Multigres 架构
12:50 纵向扩容、横向扩展与收购 Turso
17:53 开发者营销与 Meme 梗文化
23:15 产品发布会与数据迁移
31:03 向量存储、生态增长与 AI 推荐机制
41:43 产品驱动销售(PLS)与企业级增长
49:38 在线热迁移与分析型负载
58:43 面向 Agent 的本地开发环境准备
1:06:43 开发者社区生态与团队内部工作流
English / 原文
← The conversationsLatent Space Podcast
Why Agents Love Supabase
Paul Copplestone and Ant Wilson on building the backend for AI agents
Listen to this conversation77 min
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.
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
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
Thanks for reading
Stay a little ahead of the curve.
Fresh ideas, original reporting, and deep conversations in your inbox.