产品对比

Busabase 与 Supabase：给 AI Agent 用，差别在哪

Supabase 自己的建议，就是这篇文章要谈的问题最清楚的表述：「我们强烈不建议把 Supabase MCP server 连到你的生产数据库。」这个建议是对的。但它留下了一个问题——如果 Agent 不该写生产库，那它产出的东西到底该去哪？

这不是两个抢同一份活的产品之间的对比。Supabase 是应用后端，而且是很好的应用后端；Busabase 是 Agent 写入的工作区和记录系统。有用的问题是：你的问题在哪一层。对相当多的团队来说，老实的答案是「两层都要」。

核实日期：2026 年 9 月 17 日，依据 Supabase 公开的 Agent 文档与工程博客。

一句话结论

选 Supabase

：你在做应用。Auth、存储、边缘函数、OLTP、实时、向量召回——这是它的本行，Busabase 不跟它抢。

选 Busabase

：Agent 的产出本身就是交付物——记录、文档、调研、文件，人和后续 Agent 会当事实来读，而自信地写错代价很贵。

两个都用

：这也是常见情况——Agent 做出来的应用跑在 Supabase 上，而 Agent 自己的工作材料和对它的判断，放在人能审的地方。

Supabase 自己怎么说 Agent

Supabase 把自己定位成「为 agentic 工作负载打造的完整 Postgres 开发者平台」，卖点是别再「为 memory、向量、auth、文件存储和 API 拼装一堆服务」。它提供 MCP server 让 Agent 查数据、跑迁移、部署函数；提供 Agent Skills 给 Agent 程序性知识；还有行级安全（RLS），让「每一次数据库调用都遵守租户边界」。

对于「我的应用数据放哪」这个问题，这是一套完整且实现得很好的答案。

Supabase 少见地诚实的那一部分

他们自己的工程博客《AI Agents Know About Supabase. They Don't Always Use It Right.》列举了 Agent 在他们平台上会出什么错。这是他们的清单，不是我们的：

Agent 会「在暴露的 schema 上跳过 RLS 策略」；

会建出没有 security_invoker = true 的视图，「这会静默绕过 RLS」；

不知道「UPDATE 需要 SELECT 策略。没有它，更新会静默返回 0 行」；

会「幻觉出根本不存在的 CLI 命令」；

会「完全无视文档，依赖可能已经过时几个月的训练数据」；

以及直白的一句：「Agent 在这件事上很懒。」

他们的结论顺理成章：让 Agent 待在本地或 staging 库，别碰生产。

我们引用这些不是为了得分。这是两家公司公开发表过的、对 Agent 在真实后端上行为最准确的描述，而由它推出的那个建议也是对的。

为什么这是分层事实，不是 Supabase 的缺陷

注意那张清单上每一条的共同点：它们都是正确性的失败，而被指望去拦住它们的机制——RLS——管的是权限。

RLS 回答的是：这个调用方可以写这一行吗？它做得非常好。它回答不了：这个值对吗？一个权限完全正确的 Agent，把一个自信但错误的数字写进一个它完全有权写的字段，能通过数据库的每一道检查。引擎没有任何地方出错，只是这条记录是假的。

所以「别让 Agent 碰生产」是站得住的建议，而不是绕路——在引擎这一层没有别的答案可选。能拦住「有权限但写错」的那道检查不在数据库里，它在写入路径上。

那 Agent 的产出去哪

如果生产库不能碰，团队通常会落到三种安排之一，而前两种比看上去更糟：

Agent 写 staging，人再手工搬过去。

正确，但把 Agent 换来的速度基本还回去了。

Agent 写文件或聊天记录，事后有人对账。

快，但这份工作不再作为数据存在——下一轮 Agent 读不到，任何东西都归因不了。

Agent 写进一个本来就预期 Agent 写入的存储

—重要写入可以带着 diff 作为提案到达、被检查，然后才成为正式数据。

第三种就是 Busabase。不是一个更安全的数据库引擎——底下同样是 Postgres——而是在写入那一刻换了一份契约。

按你要做的事来比

你要做的事SupabaseBusabase
给应用一个后端正是本行不是它的活
Auth、存储、边缘函数、实时有无
OLTP 与高频机器写入可以不行——用 Supabase
向量召回 / RAG可以不行——用 Supabase 或向量库
控制谁可以写RLS，成熟且细粒度按节点与操作的权限
控制写下的值要不要成为正式数据不在这一层Change Request，带字段级 diff
让 Agent 安全地写生产明确不建议就是为这个设计的
记录上保留来源、提案人、审核人、历史应用自己负责内建
给人一个审 Agent 产出的界面自己做就是产品本身

Supabase 确实更好的场景

你在交付软件。

如果产物是一个有用户的应用，答案就是 Supabase，这个对比不悬。

你需要数据库原语。

迁移、连接池、边缘函数、实时订阅、成熟的 Postgres 工具链。

写入是机器量级的。

遥测、事件、高频更新。在那个量级上审核路径没有意义，我们不会假装有。

你的 Agent 是编码 Agent。

如果 Agent 的活就是写代码、跑迁移，Supabase 的 MCP server 和 Agent Skills 正对着这件事，而且他们那套 Skills 做得确实好。

什么时候你需要别的东西

Agent 的产出就是产品：补全过的记录、调研、文档、人要依赖的结构化知识。

错值代价高且不显眼——正是 RLS 结构上拦不住的那一类。

要让人在改动发生前看到它会改什么，而且你不想自己从头做这套审核界面。

你需要记录级的来源：谁提的、谁批的、依据什么，而不只是「谁拿着连接串」。

两个一起用

大多数团队最后落到的分工很直接：

Supabase 跑 Agent 做出来的应用，Busabase 是 Agent 自己干活的地方。

Agent 在 Busabase 里做调研、补全记录；人审重要写入；通过审核的记录由应用经 Busabase 的 API 读出去，而应用自身的运行数据存在 Supabase。两个产品谁也没干对方的活，谁也不需要被替换掉才能让另一个有用。

老实说说局限

Busabase 不是数据库平台。没有连接池、没有边缘函数、没有实时订阅、没有给你应用 schema 用的迁移工具、没有向量索引。如果你要的是这些，Supabase 不只是更好的选择——在这两者之间它是唯一的选择。

Busabase 也确实给相当一部分 Agent 工作加了一道没必要的步骤。低后果的写入应该快，我们也让它快；但如果你的 Agent 写的东西没有一样重要到值得看一眼，那审核路径就是你不需要的开销。

常见问题

Busabase 会取代 Supabase 吗？
不会，不同层。你的应用需要后端的话，它还是需要。
Busabase 是不是就是 Postgres 加了个审批队列？
它跑在 Postgres 上，但产品是那个工作区：Agent 和人共用的 Base、文档、文件、Skill 和小应用，审核只施加在重要的写入上。
为什么不用 RLS 加更好的提示词解决？
RLS 判断不了一个值是否为真，而提示词也没法让 Agent 变可靠——Supabase 自己那篇文章，通篇就是 Agent 无视了手边可用指令的清单。
同一轮里 Agent 能同时写 Busabase 和 Supabase 吗？
能，而且这是正常模式：运行数据写应用后端，重要且需审的产出写工作区。
那 Butterbase 和别的 Agent 后端产品呢？
同样的分层适用——它们回答的是「应用数据放哪」，不是「Agent 的产出怎么变得可信」。我们对 Supabase 做过一手研究，所以这篇只谈 Supabase，而不去断言我们没有同样细看过的产品。

下一步

如果你想验的是写入路径这个说法，最快的方式是接上你已经在用的 Agent，看一条重要写入以「你可以检查的形态」到达。

什么样的存储才算 AI Agent 的记录系统 · Busabase 与 Notion · 接入你的 Agent

来源：Supabase for Agents、《AI Agents Know About Supabase. They Don't Always Use It Right.》、Supabase AI Tools 文档。引文为 Supabase 在上述核实日期的公开原话。