Supabase vs Notion：一个是数据库，一个是工作台

会有人搜「Supabase vs Notion」，是因为这两个产品最后装的常常是同一样东西：团队的数据，摆在表格里。客户名单先住在 Notion，后来需要 API 了；用户账户先建在 Supabase，后来有人问跟进记录放哪。对比的冲动很自然——但这个对比从一开始就有点错位，因为两者根本不是同一类产品。

先给结论。 做产品、数据要被应用整天读写的，选 Supabase。管团队知识——文档、决策、项目跟进，人每天早上要打开看的，选 Notion。而如果写东西的越来越是 AI Agent，这两个答案都要改——那是本文最后一节的内容，就算前两条你早就清楚，那一节也值得看完。

两者到底是什么

Supabase 是一个 Postgres 平台。 仪表盘下面是一台真正的、独立的 PostgreSQL 数据库——完整的 SQL、约束、事务、关联查询，需要向量检索时有 pgvector——外加一圈应用后端通常要的东西：身份认证、文件存储、边缘函数、实时订阅。开发者用 SQL、REST、GraphQL API 和各语言客户端驱动它。这是一个用来「在上面做产品」的数据库。

Notion 是一个学会了表格的文档工作台。 Notion 里一切都是页面；所谓「数据库」，是给一堆页面套上属性——状态、负责人、截止日期——再加上视图、关联、汇总和公式。它极擅长人类要读、要讨论、要随手重排的工作。但它没有 SQL、没有事务、没有 join。对外接口是为集成和同步设计的 API，带速率限制，不是用来扛应用生产查询的。

就这一条区别——一个是数据库长出了友好的平台外围，一个是文档工具长出了数据库形状的表格——决定了下面几乎每一行。

正面对比

	Supabase	Notion
本职工作	你产品的后端与数据存储	团队的文档与共享知识
数据模型	真正的 Postgres 表：类型化字段、外键、约束	带属性的页面；数据库之间有关联与汇总
查询	完整 SQL、join、聚合、索引	视图里的筛选、排序与公式；API 带筛选查询
程序化接入	SQL、REST、GraphQL、客户端库、CLI	公开 API 与 webhook，有速率限制，面向同步
协作	开发者工具，非技术同事基本不会打开	评论、@、共同编辑——团队本来就住在里面
自动化	数据库触发器、边缘函数、定时任务	工作区内的按钮与数据库自动化
价格形态	按项目与用量：Pro 为每组织每月 $25（含计算额度），超出后按量计费	按成员：每个同事一个席位；访客免费但受限
Agent 接入现状	官方 MCP 服务器，可限定单个项目、可开只读模式	官方 MCP 服务器，Agent 以你本人的权限行事
Agent 写入治理	没有给 Agent 写入设的审核层——控制手段是限范围与只读	没有给 Agent 写入设的审核层——边界就是你本人的权限

Supabase 赢在哪

凡是软件要依赖的数据。应用要问「这个用户有哪些未付订单，关联库存，在一个事务里查完」——这是 Postgres 的问题，Notion 听不懂。Supabase 还赢在数据纪律：约束和外键在门口就拦住坏数据，而不是任由它在某个手填属性里攒起来；行级安全策略（RLS）让数据库自己执行谁能看什么；做 AI 功能时，pgvector 让向量和它描述的行住在一起，不必再养第二套系统。

代价也要说清：Supabase 是开发者工具。运营负责人不会乐意在表格编辑器里审内容，没人会在里面写会议纪要；费用从每月 $25 起步，但随计算与流量增长按量走。

Notion 赢在哪

凡是团队要读的东西。项目跟进、决策记录、入职文档、创始人真的会亲手更新的那张 CRM 形态的名单——Notion 赢，因为人本来就在里面，而一个没人打开的数据库只会烂掉。它的表格对早期工作的「不规范」很宽容：加个属性、换个视图、把文档贴进一条记录。评论和 @ 让它是一个协作面，而不只是存储。

代价同样真实：宽容是双刃的。没有约束，同一个状态能攒出三种写法；查询止步于筛选和汇总，问题一旦需要 join，就有人导出到电子表格。按成员计价意味着工作区的成本随人数涨，与你存了多少数据无关。

两个都用——以及那条唯一的规矩

大多数团队最后两个都有，这没有问题：Notion 管叙事（计划、纪要、决策），Supabase 管应用（账户、订单、产品数据）。这种组合只会在一种情况下翻车：同一份数据悄悄在两边各存一份、两边都在改，然后没人说得清哪份是真的。防住它只需要一条规矩：每份数据只有一个权威住所，另一边只能链接，不许手工镜像。 人维护的，住 Notion；软件依赖的，住 Supabase。有争议，到此为止。

会改变答案的那个问题：谁在写？

上面全部讨论都默认「人写、软件读」。这个默认正在过期。两家现在都提供官方 MCP 服务器，Agent 今天就能接上任何一边——细节很关键：

Supabase 的 MCP 服务器可以限定到单个项目，并可切换到只读模式（所有查询以只读 Postgres 用户执行）。Supabase 官方文档把它定位在开发与测试场景，明确提醒生产数据的风险，并建议在你的 Agent 客户端里保持「工具调用需人工确认」开启。
Notion 的 MCP 服务器用 OAuth 登录，以你本人的权限行事——可以在整个工作区里搜索、读取、新建和更新页面与数据库。

注意两家的共同点：它们治理的是接入，不是写入。控制手段决定 Agent 能碰什么；但写入一旦发生，就直接、终局地落下去。所谓审批——如果有的话——是你聊天客户端在当下问一句「执行这个工具调用吗」，而不是数据层上一个可审的提案：带 diff、队友可以明天再看、可以讨论、可以合并或驳回。两家都没有区分「Agent 提议的数据」和「团队接受的数据」。

一旦 Agent 每天都在写，这个区分就是全部的游戏。Agent 更新的 CRM、Agent 维护的知识库、Agent 夜里归档的记录——你不需要拖慢 Agent，你需要的是：它的写入在分量重时以提案形式到达，在分量轻时直接落地。Busabase 就是为这一层而建的，可以把它看成给 Agent 用的 Notion + Supabase 混合体：记录、文档与 Skills 在同一个工作区，Agent 的每一次写入都是带 diff 和历史的变更请求。用有写权限的密钥，写入直接合并；用「只能提议」的密钥，它就等人审核。每个 Agent 都能通过 MCP、Agent Skill、API 或 CLI 接入。价格是按席位的平价（Plus 每席位每月 $10、Pro $20，按年付），没有按量计费；引擎开源，想自己托管记录层也可以。逐项对比见 Busabase 与 Supabase 对比；更长的论证在《Supabase 与 Busabase：记忆与规则层》。

按场景裁决

你的情况	建在谁上面
产品数据要被应用频繁查询	Supabase
团队知识、文档与跟进，由人维护	Notion
两者都有（大多数团队最终如此）	两个都用——每份数据一个权威住所
记录与知识由 Agent 写、人必须能信任	为 Agent 写入而建的记录层：可看 Busabase vs Notion 和 Busabase vs Supabase

常见问题

Notion 能当我应用的数据库吗？ 原型和内部工具阶段，有团队这么用。上限来得很快：没有 SQL、没有 join、没有事务，API 是为同步而非生产流量建的。数据一旦被真正的软件依赖，就搬去真数据库，Notion 改为链接过去。

Supabase 能替代 Notion 放团队文档吗？ 你可以把文字存进 Postgres。存不进去的是习惯——没有文档编辑体验、没有评论文化、没有一页是团队每天早上自愿打开的。没人读的 wiki，比没有 wiki 更糟。

哪个更便宜？ 小规模时两家都接近免费，这个问题不值得纠结。形态不同——Notion 随人数涨，Supabase 随项目与用量涨——但真正贵的从来不是订阅费，而是选错了形态、让一年的数据在里面攒下来、最后付迁移的账。