为什么 AI 智能体偏爱 Supabase？

AI 智能体可以生成应用代码，但要让应用真正运行起来，仍需配置数据库、管理结构变更、部署计算任务，并在出错时找到原因。Supabase 面向智能体的产品方向，正是在减少这些环节中的摩擦。

围绕联合创始人 Paul Copplestone 和 Ant Wilson 的讨论，可以从构建、运行与扩展三个层面，理解它为什么适合智能体驱动的开发流程。

让智能体更容易启动和理解后端

Supabase 推出了无需 Docker 即可在本地运行的新版运行时，目前处于 Alpha 阶段。

对人类开发者而言，本地环境配置可能只是偶尔需要处理的工作；对不断创建项目、启动环境并执行测试的智能体而言，这一步会反复出现。减少一个依赖，也就减少了一处可能阻断自动化流程的环节。

传统数据库工作流通常依赖不断累积的迁移记录：先创建结构，再一次次修改。要理解当前状态，往往需要结合迁移历史进行还原。

声明式数据库结构则把关注点转向“数据库应该是什么样”。目标结构保存在文件中，与应用代码一起纳入 Git，智能体可以直接读取、修改，并在分支中处理这些文件。

这类似于 Terraform 对基础设施的管理方式：把期望状态显式写出来，而不是只保留通往当前状态的操作历史。

这种方式同样有利于人类开发者。理解后端时，不必完全依赖对历次迁移的追溯。

应用不仅要保存结果，也要执行产生结果的任务。例如，文档切分、生成嵌入向量，以及其他耗时较长的处理工作，都需要计算环境。

处于私有 Alpha 阶段的 Supabase Compute，尝试让容器工作负载运行在靠近数据库的位置。

其意义在于缩短“应用能启动”与“应用能持续运行”之间的距离：开发者需要单独配置、连接的服务更少，智能体也少了一些必须理解和协调的组件。边缘函数仍有用途，但并不能覆盖所有工作负载。

智能体即使具备执行 SQL 的能力，也仍然需要知道：

因此，日志、检查、连接信息和运行上下文，并不是构建功能之外的附属品。它们帮助智能体判断自己正在修改什么，以及修改后发生了什么。

理解 Supabase 的智能体方向，不能只看它如何帮助生成应用，也要看它如何让应用状态更容易被观察和理解。

Paul 和 Ant 表示，Supabase 每月启动的数据库数量约为 500 万个。他们一方面在思考智能体推动应用数量继续增长的可能性，另一方面也需要支持现有客户不断增大的工作负载。

这对应两类不同的工程挑战：

Supabase 围绕规模扩展的布局涉及 OrioleDB、Multigres，以及对 Turso 的收购。讨论也涉及 PostgreSQL 的可靠性，以及纵向扩容与横向扩展之间的取舍。其中，Multigres 面向高可用 PostgreSQL，目前处于私有 Alpha 阶段。

这些方向共同构成了其“从原型到 PB 级”的产品定位，但不应把这一定位直接理解为所有相关能力都已成熟可用。

两位创始人还分享了一项观察：随着 AI 驱动的使用增长，产品激活和转化有所改善。他们给出的解释是，智能体能够把用户从注册带到可运行的配置，串成一条连续流程，让用户不必先弄懂每个配置步骤，才能看到应用工作。

这里没有给出具体提升幅度，因此更适合把它视为团队对使用行为的观察，而不是普遍适用的增长结论。

Supabase 的案例提示了一个值得讨论的问题：面向智能体优化开发工具，核心是否并非增加一个 AI 入口，而是让环境更容易启动、目标状态更清晰、运行过程更可理解？ 这些改进对智能体有用，也同样能减少人类开发者的工作负担。