Supabase 和 Firebase 区别（2026）：AI 应用该选哪个后端

如果你的应用以数据为核心、你想用 SQL、并且你觉得将来有可能要搬走，那就选 Supabase；如果你要发布的是一款实时移动应用，并且不想在第一天就折腾计费配置，那就选 Firebase。剩下的全部内容，就是成本账，以及这两家各自会撞上的那堵墙。

两者都属于“后端即服务”（backend-as-a-service）：数据库、认证、文件存储和 API 都由平台替你托管，你永远不用自己去起一台服务器。相似之处到此为止。它们以完全不同的形态存储数据，采用相反的计费模型，而且其中一家你随时可以走人，另一家基本走不掉。对 2026 年的一款 AI 应用来说，这三点差异比任何功能清单都更能决定结果。

先看结论，再看支撑结论的账。

该选哪个，取决于你在做什么

如果你的应用主要由互相关联的表构成（用户、订单、帖子、评论），而你会写或至少看得懂 SQL，那就构建在 Supabase 上。你拿到的是一个真正的 PostgreSQL 数据库，这意味着 join、事务，以及一套把脏数据挡在门外的 schema。它还是开源的，所以等哪天托管套餐不够用了，你可以把整个数据库端走，放到任何地方跑起来。这道后门的价值，大多数创业者要到真的需要时才意识到。

如果你的应用核心功能是跨设备实时同步的状态（聊天应用、协作工具，任何必须在离线时也感觉即时的东西），那就构建在 Firebase 上。Firestore 的实时同步和离线持久化至今仍是业界标杆，而且你连信用卡都不用填就能上线。代价是你在用 Google 的规则向 Google 租用服务，账单按操作次数计量——团队被“惊喜”到的地方，正是这里。

下面的内容，就是这两个判断在真实价格、真实 AI 功能，以及那些在你上了生产环境之后才见分晓的坑面前，究竟站不站得住。

真正决定选择的唯一一条标准

把功能清单都拿掉，区分这两者的只剩一个问题：你拥有一个可以带走的数据库，还是在租一项走不掉的服务？

Supabase 就是 PostgreSQL 加一层控制台。PostgreSQL 是全世界部署最广的开源关系型数据库，而 Supabase 既没有 fork 它，也没有把它藏起来。你拿到的是原始连接串。如果哪天你想迁到自己的服务器、迁到 AWS、或者换一家托管商，跑一个标准的 pg_dump 就能走人。你的数据里没有任何专有的东西。

Firebase 就是 Firestore，一个只存在于 Google 内部的 NoSQL 文档数据库。NoSQL 意味着没有固定 schema：你存的是类 JSON 的文档，数据库不会强制它们之间的关系。这让早期原型开发很快，因为你从不需要停下来设计表结构。但这同样意味着没有 SQL、没有真正的 join，也没有一条干净的路径把数据导出到别的系统里去。数据模型和供应商是同一个决定。Firestore 你带不走。

对大多数 AI 应用来说，答案偏向 Supabase，因为 AI 功能依赖结构化、可查询的数据：一张用户表、一张文档表、一列可以过滤和 join 的 embedding。NoSQL 也能做，但你最终会在应用代码里重新造一遍 SQL 免费给你的东西。例外是当“跨设备即时同步”本身就是产品的时候——那是 Firestore 做得比谁都好的一件事。

:::callout{variant="note" title=""关系型"在实际开发中到底换来了什么"}
假设一个用户注销账号，他创建过的每一条评论、每一个赞、每一个文件都必须一并消失。在 PostgreSQL 里，这是一条只定义一次的规则（一个带级联删除的外键），数据库会永远替你执行它。在 Firestore 里，你得自己写代码去查找并删除每一份关联文档，只要漏掉一条路径，孤儿数据就会越堆越多。关系型数据库把“属于同一组的数据保持一致”变成数据库的活儿，而不是你的活儿。
:::

定价：几乎所有人都搞错的部分

关键不是月费数字，而是计费模型。Supabase 收一个固定档位加上可预测的超额费用；Firebase 按操作次数收费，所以你的账单会跟着流量走，有时候一夜之间就变了。

Supabase：一个你能拿来做预算的固定数字

Supabase Free 是 $0，而且足以撑起一个真实应用：50,000 月活用户、500 MB 数据库、5 GB 出站流量、1 GB 文件存储。所有人都会踩的那个坑是：免费项目在闲置一周后会被暂停，而且你最多只能有 2 个活跃项目。项目被暂停意味着你的 demo 一直躺着，直到你点一下把它恢复——对副业项目无所谓，但对任何客户可能随时打开的东西来说就是问题。

Supabase Pro 是每月 $25，含第一个项目，额外项目每月 $10 起。这 $25 买到的是 100,000 MAU（超出后每个 MAU $0.00325）、每个项目 8 GB 磁盘（超出后 $0.125/GB）、250 GB 出站流量（超出后 $0.09/GB）、100 GB 文件存储（超出后 $0.0213/GB）。它还包含每月 $10 的计算额度，足够跑一个常驻的小实例。Team 套餐直接跳到每月 $599，主要加的是合规能力（SOC2、ISO、SSO）；在那之下你用不着它。

开发者喜欢这个模型的原因是：你看一眼用户数就知道账单是多少。$25 的 Pro 能撑起一个真正的生产应用，而超额费率足够低，10,000 个活跃用户加上几个 GB 的数据，账单仍然落在 $25 到 $50 这个区间。

Firebase：免费到不免费为止，然后开始按量计费

Firebase Spark 是真正意义上的免费套餐，它最大的优点是完全不需要任何支付方式。你能拿到 Firestore 的 1 GiB 存储、每天 50K 次读、每天 20K 次写、每天 20K 次删除，以及每月 10 GiB 出站流量；Authentication 支持 50K 月活用户；Realtime Database 提供 1 GB 存储和每月 10 GB 下载。对一个原型或低流量应用来说，你可以无限期地待在 Spark 上，一分钱不花，也不用留卡。

一旦你需要更多，就要切到 Blaze，也就是按量付费套餐（符合条件的话 Google 会送 $300 免费额度）。Blaze 保留 Spark 的免费额度，然后对超出部分全部计量：Cloud Functions 每月 2M 次调用免费，之后每百万次 $0.40；Cloud Storage 超过 5 GB 的存储按 $0.026/GB，超过每天 1 GB 的下载按 $0.12/GB；Firestore 超出每日免费额度的读、写、删除，按 Google Cloud 的价目表逐次计费。Firebase 现在还通过 SQL Connect 提供托管 PostgreSQL，3 个月免费试用，之后大约每月 $9.37 起——这算是一种安静的承认：说到底，很多人还是想要 SQL。

免费额度正面对比

两家都给你 50,000 月活用户的免费额度，这足以验证几乎任何想法。差别在于两个坑。

Supabase 的坑是暂停：让一个免费项目闲置一周，它就会睡过去，直到你把它叫醒。做 demo 时很烦，但等你有了真实流量或升级到 Pro 之后就无所谓了。

Firebase 的坑是升级断崖：Spark 确实免费、确实不用卡，但你一旦超出它，就直接落到按量计费上，而按量计费在设计上就是不可预测的。这里没有一个 $25 的“我就想花固定的钱多要一点”的中间档。你是从免费一步跨到按用量付费。

所以关于免费额度的诚实结论是：对一个零承诺、可能永远不会变现的原型，Firebase 赢——不用卡，也不会暂停。而当项目变成真格的那一刻，Supabase 赢，因为固定 $25 强过“我们先给你计量，然后再看看”。

Supabase 和 Firebase 区别最大的地方：做 AI 应用

这正是 2026 年真正区别于 2022 年的地方，也是 Supabase 对大多数开发者拉开差距的地方。一个 AI 应用通常需要存储 embedding（你的文本的数值指纹），并找出与查询最接近的匹配项。这就是向量检索，是检索、语义搜索和 RAG（retrieval-augmented generation，把你自己的文档喂给 LLM）背后的引擎。

Supabase 通过 pgvector 原生提供这一能力，这是一个 PostgreSQL 扩展，把向量和你的普通数据存放并索引在一起。因为是同一个数据库，你可以用一条查询同时按用户 ID 过滤并按向量相似度排序。不需要第二套系统，也不需要同步。Supabase 的 AI 工具包还能直接对接 OpenAI 和 Hugging Face 的 embedding。

Firebase 的回应是 Firestore 通过 findNearest 查询实现的向量检索，你可以把 embedding 存在文档上，不离开 Firestore 就取回最近邻。它能用，而且如果你已经深度绑定 Firestore，它替你省下一个数据库。但你是在一个当初并非围绕向量设计的文档存储里做向量运算，同时失去了那种让 pgvector 查询如此干净的 SQL 过滤能力。对一个 AI 优先的应用来说，pgvector 是更自然的归宿。

1. 1

   在 Supabase 上存一个 embedding

   用 create extension vector; 启用扩展，给表加上一列 embedding vector(1536)，然后把 embedding 数组和这一行的普通数据一起插进去。一张表同时装着你的内容和它的向量。

2. 2

   查询最接近的匹配项

   跑一条普通的 select，按向量距离运算符（embedding <=> query_embedding）排序并加上 limit。你可以在同一条查询里加上常规的 where user_id = ...，这样相似度检索和访问控制就在一次往返里同时完成。

3. 3

   建索引，让它一直保持快

   在向量列上加一个 HNSW 索引。它能让最近邻查找在表变大时依然很快，就像普通索引加速普通列一样。

认证、实时同步，以及其他

认证方面两家都做得不错。Firebase Auth 更成熟，支持的身份提供商列表很长，移动端 SDK 也最顺滑；如果“让用户登录”这件事必须在 iOS 和 Android 上直接跑通，它非常出色。Supabase Auth 建立在你自己的 Postgres 数据库之上，并与 RLS（row-level security，行级安全：每个用户只能读写属于自己的行，由数据库本身来强制执行）配套。RLS 是学习 Supabase 时最重要的一个概念，因为正是它让一个多用户应用在你不必给每个 API 调用都写权限检查的情况下依然安全。

实时同步是 Firebase 的主场。Firestore 和 Realtime Database 会跨设备同步状态，并优雅地处理离线场景：把写操作排队，等连接恢复后重放。Supabase 也有 Realtime，建立在 Postgres 的变更流之上，用于实时看板和在线状态很不错，但它不是 Firebase 移动应用所依赖的那种离线优先体验。如果你的产品是一款协作型或重度离线的移动应用，这一项应该给 Firebase 加很重的分。

按你是谁来决定

Supabase 和 Firebase 哪个更好？

没有绝对更好的一方。Supabase 更适合需要 SQL、需要 AI 功能、并且希望将来能自由迁移的数据密集型应用。Firebase 更适合实时、离线优先的移动应用，以及不需要信用卡、零承诺的原型。按照你的核心功能到底是结构化数据还是实时同步来选工具。

Google 是不是要关停 Firebase？

Google 并没有关停 Firebase。这种误解来自两件事：一些历史产品被弃用（例如 Firebase Dynamic Links 已于 2025 年 8 月停止服务），以及 Google 把部分功能并入了 Google Cloud。核心平台仍在积极开发，近期新增的包括 Firebase Studio、AI Logic，以及通过 SQL Connect 提供的托管 PostgreSQL。

Supabase 属于 Firebase 吗？

不属于。Supabase 是一家独立的公司，常被描述为开源版的 Firebase 替代品。它提供同一类一站式后端（数据库、认证、存储、API），但建立在 PostgreSQL 之上，而不是 Google 那套专有的 Firestore。

Supabase 有哪些缺点？

主要有两点。免费项目在闲置一周后会被暂停，这会打断演示。另外，它的实时和离线同步体验虽然扎实，但成熟度不如 Firebase，所以对重度离线的移动应用，Firebase 仍然占优。你还需要学会 RLS，才能保证多用户应用的安全。

Supabase 和 Firebase 哪个更便宜？

对一个真正零流量的原型，Firebase Spark 更便宜，因为它免费且不用绑卡。一旦有了真实用量，Supabase 通常更便宜，也可预测得多：每月固定 $25 的 Pro 套餐，对比 Firebase 那种随流量上涨的按操作计费。你的应用读写越多，Supabase 的固定模型就越占上风。

先选好后端，再让技术栈的其余部分与之匹配。我每周会发出一份这样的工具拆解，包括真实成本和会撞上的墙。发到你的邮箱。