为什么智能体偏爱 Supabase — Latent Space

我第一次见到 Paul Copplestone 和 Ant Wilson，是在新加坡，当时他们刚结束 YC 项目，是 YC S20 最火的初创公司。六年后，我们终于请他们上了播客！这是他们首次共同做客播客；此前，他们把一家开源、完全远程办公的公司从零发展到估值 100 亿美元。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.

这个标题是我自己一直想弄明白的一个问题：为什么智能体都喜欢 Supabase？托管数据库有很多选择，Postgres 托管服务的竞争也很激烈。对模型来说，熟悉某个产品有助于推广，但这并不能解释为什么要做那么多工作，才能把生成的应用变成真正能运行的东西。不过，当我运行自己的前沿 AEO 跟踪器时，发现从 Astra、Fable 到 Muse，所有前沿模型几乎都把 Supabase 列为应用后端的首选（在托管数据库方面也名列前茅）。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.

在 Select 大会上，Supabase 将其公告划分为“构建”“运营”和“扩展”三大板块。At Select, Supabase grouped its announcements into Build, Operate and Scale.

让我印象深刻的内容出乎意料地务实：无需 Docker 即可启动本地后端，将预期的数据库架构保存在 Git 中，并在数据库旁运行计算任务。每一项都省去了开发者多年来一直在做的一部分工作。智能体让这种摩擦更难被忽视。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

我最喜欢的开发工具公告，总会让我觉得：我当然想今天就用上这个。Supabase 推出的新 alpha 运行时，可以在本地运行 Supabase 而无需 Docker，就是其中之一。我用的是 Colima，而不是 Docker Desktop；即便如此，能从搭建可用数据库的流程中再去掉一个依赖，也很受欢迎。本地环境配置只占人类开发者一周中很小一部分时间；但一个反复创建和测试环境的智能体，会一次又一次地遇到它。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.

声明式数据库模式才是更大的理念。我们熟悉的 SQL 工作流会不断积累历史记录：创建模式，然后迁移、迁移、再迁移。声明式表示则通过文件描述你想要的状态，代理可以像处理应用程序一样检查和编辑这些文件。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.

在评论中，我将此比作数据库的 Terraform 时刻。把期望状态放进 Git，智能体就可以读取、修改、分叉，并将其作为仓库的一部分开展工作。人类也能获得同样的优势：无需重建整个历史，就能更轻松地理解后端。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

我认为 Supabase Compute（目前处于私人 alpha 测试阶段）的价值可能被低估了。应用既需要一个处理工作的地方，也需要一个存储结果的地方。有了数据库之后，你仍然需要一个地方来运行处理流程，例如对文档进行分块、生成嵌入向量，或执行其他耗时较长的任务。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 和 Ant 讨论了在数据库附近运行容器。这弥合了启动应用与运维应用之间的差距：需要配置、连接并向智能体说明的独立服务更少了。边缘函数仍然有用，但无法覆盖所有工作负载。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.

运维侧同样重要。日志、检查、连接和上下文有助于智能体理解自己正在更改什么。即使模型能够执行 SQL，也仍需了解数据库中有什么、应用如何使用数据库，以及出现故障时发生了什么。阅读 Supabase 关于 Operate 的公告，也能与了解新的构建方式相辅相成。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

创始人表示，Supabase 每月启动约五百万个数据库。他们正在思考，如果智能体将这一数字推向数十亿个应用，会发生什么。与此同时，现有客户的工作负载也在不断扩大。为更多小型数据库提供服务，与支持客户规模日益庞大的数据库，是两种不同的工程问题。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.

这有助于解释 Scale 一系列公告的广度：OrioleDB、Multigres 以及对 Turso 的收购。对话深入探讨了“从原型到拍字节”这一新定位背后的工作，包括 Postgres 的可靠性，以及纵向扩展和横向扩展所涉及的选择。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.

Paul 和 Ant 的一项观察对任何开发者工具的构建者来说都特别有意思：他们表示，随着 AI 驱动的使用不断增长，用户激活率和转化率也有所提升。他们的解释是，智能体可以在一个流程中引导用户从注册到完成可用的配置。用户不必先弄清楚每个配置步骤，才能看到应用运行起来。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.

我们还聊到了帮助 Supabase 壮大的梗图和社区、开源项目的采用与企业销售，以及各类智能体是否会逐渐趋同于相同的应用模式。不过，我也希望这一期能展现创始人之间的默契。你可以听到 Paul 和 Ant 一起探讨产品，也能看到一个智能体轻轻松松就能呈现出来的后端，背后其实凝聚了多少工作。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 — 与数据库一同运行工作负载。

  Supabase Compute — run workloads alongside the database.

• Multigres——该团队针对高可用 Postgres 的方案，目前处于封闭式 Alpha 阶段。

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

• Supabase 收购 Turso——这是支撑其横向扩展雄心的数据库架构。

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

• Supabase Select——本次对话中讨论的活动。

  Supabase Select — the event discussed in this conversation.

章节Chapters

0:00 欢迎，以及智能体为何青睐 Supabase 5:23 Paul Copplestone 和 Ant Wilson 6:39 在数据库旁运行计算 8:05 OrioleDB 和 Multigres 12:50 纵向扩展、横向扩展与 Turso 17:53 面向开发者的营销与网络迷因 23:15 发布与迁移 31:03 向量、增长与 AI 推荐 41:43 产品驱动型销售与企业增长 49:38 实时迁移与分析 58:43 面向智能体的本地开发 1:06:43 社区与公司工作流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