Supabase、Firebase、PlanetScale：真实数据库成本拆解
2025 年初，一个独立开发者在 Firestore 上跑 MVP。三月份，读密集的仪表盘每天产生 420 万次读取。Firebase 账单飙到 $387/月——那时候他一个付费用户都没有。周末他迁到 Supabase，账单变成 $25。同样的数据，同样的功能，十分之一的价格。
这就是没人会在黑客马拉松上告诉你的数据库成本陷阱。选后端不是看哪个 logo 更酷——而是你的访问模式怎么匹配定价模型。我们拆解三个最受独立开发者欢迎的选项，算清楚你实际要付多少钱。
Supabase、Firebase 和 PlanetScale 分别是什么？
这是三种完全不同的数据库托管方案，各自针对不同的工作负载哲学做了优化。
Supabase 是基于 PostgreSQL 的开源 Firebase 替代品。完整的关系型数据库、认证、实时订阅、存储、Edge Functions 一站式提供。价格按层级固定：免费版（500 MB、50K MAU）、Pro 版 $25/月（8 GB、100K MAU）、Team 版 $599/月。你为数据库容量和带宽付费，不按读取次数计费。
Firebase (Firestore) 是 Google 的 NoSQL 文档数据库，默认无服务器架构。定价是纯按量付费：$0.18/GB 存储、每 10 万次读取 $0.06、每 10 万次写入 $0.12。Blaze 计划最低 $25/月起。
PlanetScale 是基于 Vitess 构建的 MySQL 兼容无服务器数据库。杀手锏是分支功能——像 Git 分支一样管理数据库 Schema。Hobby 免费版 1 GB。Scaler $39/月（10 GB、100 亿行读取）。Scaler Pro $99/月。企业版定制。
三个用户规模下的真实成本
假设一个典型的 B2B SaaS，读写比例中等：每个活跃用户每次会话约产生 200 次读取和 20 次写入，每天 3 次会话。
| 月活用户 | Supabase (Pro) | Firebase (Firestore) | PlanetScale (Scaler) |
|---|---|---|---|
| 1,000 | $25（免费版够用） | ~$5（免费额度内） | $39 |
| 10,000 | $25 | ~$35–60 | $39 |
| 100,000 | $25–50（可能需附加服务） | $300–500+ | $99 (Scaler Pro) |
1,000 用户时，PlanetScale 是最贵的——你为用不上的容量付 $39/月。Firebase 靠慷慨的免费读取额度看起来最便宜。Supabase 在 $25 的位置居中。
到 100,000 用户时，局势反转。Firebase 的按读计费迅速累积。一个每 30 秒自动刷新的仪表盘，每个用户每天增加数万次读取。PlanetScale 在 $99/月封顶，行读取上限可预测。Supabase 保持平坦，除非数据量超出层级。
Firebase 的隐藏成本：读取乘数效应
Firestore 按文档读取次数收费，不是按查询次数。拉取一个 10 条结果的列表，读 10 个文档。如果你用嵌套文档结构——比如 用户→项目→任务——一次「加载我的任务」操作可能读取 50+ 个文档。乘以 10 万用户同时刷实时仪表盘，账单直接爆炸。
解决方案存在（激进反规范化、复合查询、Redis 缓存），但需要大多数独立创始人在 MVP 阶段没时间做的架构纪律。本质上你在优化数据模型来服务定价模型，而不是产品需求。
与 Supabase 和 PlanetScale 不同，Firestore 没有关系型查询规划器。你不能 JOIN。不能做复杂聚合，除非用 Cloud Functions，而那有独立计费。每个读取 Firestore 的 Cloud Function 调用都会触发新一轮文档读取。
Supabase 什么时候赢（什么时候不赢）
Supabase 适合用 SQL 思考的创始人。完整 PostgreSQL——JOIN、CTE、窗口函数、PostGIS 和 pgvector 等扩展。行级安全策略住在数据库里，不在应用代码中。$25 Pro 版覆盖大多数独立 SaaS 工作负载，一直到 10 万用户。
我们在 Trove Deck Solution 帮一个客户做的实时分析仪表盘就跑在 Supabase 上。他们的模式：重写入（事件采集）、中度读取（聚合视图）。Supabase Pro 版轻松搞定，因为定价模型不像 Firestore 那样惩罚写入量。
Supabase 在哪里翻车：连接数限制。免费版 60 个并发连接上限。Pro 版更多，但如果你跑后台任务工作器开着持久连接，你会撞上天花板。修复方案是 PgBouncer（Supabase 支持），但增加了一层运维复杂度。
另外，Supabase Edge Functions 跑在 Deno 上，不是 Node.js。如果你的后端逻辑依赖特定 npm 包生态，会有摩擦。
PlanetScale：分支溢价
PlanetScale 的 Schema 分支功能确实独一无二。你可以并行运行两个版本的数据库 Schema，用生产流量模式测试迁移，确认后合并。对于每周都在迭代数据模型的团队，这个功能值得溢价。
代价是：PlanetScale 在 2024 年取消了无服务器层级的外键支持（建议应用层参照完整性）。如果你的 Schema 有深层关系依赖需要在数据库级别强制执行，这是硬伤。你也被锁定在 MySQL 语法里——没有 Postgres 扩展，没有 Postgres 那么灵活的 JSON 操作符。
$39 Scaler 层级给你每月 100 亿行读取。大多数 1 万到 5 万 MAU 的 SaaS 应用够用了。$99 Scaler Pro 有效提供无限读写。三条产品线里，成本曲线最平。
五步决策框架
n 1. 映射你的读写比例。 如果读取次数是写入的 50 倍以上，避开 Firestore，除非你预算做反规范化的工作。 2. 统计并发连接数。 如果你跑后台工作器或长轮询，Supabase 的连接限制很关键。PlanetScale 的无服务器模型绕过了这个问题。 3. 估算数据增长。 如果 6 个月内会超过 10 GB，Supabase 的层级跳转很陡（Team 版 $599）。PlanetScale Scaler Pro $99 更宽容。 4. 评估查询复杂度。 需要 JOIN、聚合或地理空间查询？Supabase + Postgres 明显胜出。Firestore 需要变通方案。 5. 算上迁移成本。 离开 Firebase 意味着重写整个数据访问层。在 Supabase 和 PlanetScale 之间迁移意味着移植 SQL 方言。有意识地选择你的锁定级别。
大多数创始人犯的错
最大的错误是为免费层级优化，而不是为 10 万用户层级优化。免费层级是营销工具。它们的设计目的是把你的数据拉进来，不是当你的生产基础设施。
第二个错误：忽略出口流量费用。三家供应商在免费额度之后都收带宽费。Supabase Pro 版包含 250 GB 带宽。Firebase 免费 1 GB/天，之后 $0.12/GB。PlanetScale 按层级包含不同额度。如果你的应用服务大负载——图片密集的仪表盘或 CSV 导出——出口费用可能超过数据库计算成本。
第三个错误：以为「无服务器」意味着「零运维」。三家都需要监控。Firebase 需要读写预算管理。Supabase 需要连接池调优。PlanetScale 需要 Schema 迁移纪律。运维负担只是换了形式——没有消失。
结论
对大多数构建传统 Web 应用的独立创始人来说，Supabase $25/月是最优性价比。一个账单覆盖 Postgres、认证、实时功能和存储。定价模型奖励你写高效的 SQL，这是一项值得培养的技能。
Firebase 只在你的应用天然是实时协作场景（聊天、多人、实时仪表盘）且你愿意投入反规范化时才是正确选择。PlanetScale 值得溢价，如果 Schema 迭代速度是你的瓶颈且你习惯 MySQL。
无论选哪个，在写第一行代码之前按你的目标用户数跑一遍成本预测。你第一天选的数据库，就是第 400 天要迁移的那个。
在做自定义 SaaS 不确定哪个数据库技术栈适合你的架构？Trove Deck Solution 的团队在三个平台上都交付过生产应用，可以帮你针对具体用例算清楚账。