Supabase还是Firebase：SQL控制与实时能力如何取舍

聊天应用若会持续增加成员权限、跨会话查询和数据迁移需求，优先考虑 Supabase 的 PostgreSQL 路径；若移动端实时同步与离线使用决定产品体验，Firebase 的 Cloud Firestore 更直接。两者都能承载登录、消息和附件，选择的代价主要体现在数据怎样组织、实时更新怎样送达，以及业务增长后按什么计费。

独立开发者和小团队不能只比较免费额度或起步月费。同样数量的用户，可能每天只打开一次会话，也可能反复加载历史消息、长时间保持订阅并下载大量图片。下面以同一款假设的聊天应用对齐这些行为；费用演算只使用公开价格与明确假设，不代表平台性能测试。

成员、会话和消息怎样组织

Zapier 的平台对照将 Supabase 的 PostgreSQL 与 Firebase 的 Cloud Firestore 分别置于关系型和文档型路线，并认为 Firebase 的实时能力更成熟。对聊天应用来说，这个差别首先落在成员、会话、会话成员关系、消息和已读状态的建模方式上。

在 PostgreSQL 中，团队可以为这些实体建立关联表，用外键维护关系，再用 SQL 组合筛选条件。例如，“列出我参与且仍有未读消息的会话，并按成员角色过滤”，可以沿着已有关系查询；相应地，团队需要设计表结构、索引、行级安全策略和后续迁移。权限越依赖多个实体之间的关系，这种可控性越有价值。

在文档型路线中，消息可以放在会话下的文档集合里，客户端按会话读取并监听结果。若页面同时需要成员角色、多个会话属性和未读计数，团队就要围绕实际查询安排文档、索引及可能的冗余字段，并决定重复数据如何更新。两种路线都要做建模工作，只是复杂度分别更多地出现在关系设计和访问模式设计上。

这里比较的是 Firebase 的 Cloud Firestore 路径。Firebase 还提供以 Cloud SQL for PostgreSQL 为基础的 SQL Connect；选择它需要另算操作数、网络传出和数据库实例费用，不能把它视为 Firestore 查询的另一种写法。

实时与离线体验改变多少工程工作

Cloud Firestore 的查询监听和离线持久化可直接用于客户端：数据变化会更新监听结果，移动端或网页端断线后也能使用本地缓存。重新联网时，应用仍须处理同步后的状态；监听结果的首次读取、文档变化及部分重连情形，则可能增加计费读取。对以移动端聊天为核心的产品，这套现成能力能减少团队自行维护本地同步逻辑的工作。

Supabase Realtime 可以订阅 Postgres Changes，也可以用 Broadcast 分发消息。前者便于让客户端看到数据库变化；如果大量用户监听同类变化，订阅者的授权检查会增加扩展压力。Broadcast 能提供另一条分发路径，但频道权限和消息发送方式需要额外设计。选择时应估计一条消息会送达多少在线成员，而不只是数据库新增了多少行。

如果产品必须在弱网中允许用户继续发送消息，使用 Supabase 的团队还需安排本地队列、重试、去重与冲突处理。反过来，主要在稳定网络中使用的网页应用，可能更重视跨表查询和权限模型。实时功能是否“成熟”并不能单独决定平台选择，关键是团队需要平台预先承担哪部分工作。

认证和附件为什么要单独估算

假设用户发送一张图片：数据库可以只保存带文件路径的消息，文件本身由存储服务保存；其他成员打开图片时，还会产生下载流量。文字消息则更容易因反复加载历史记录和实时监听积累读取次数。只用注册用户数推算账单，会漏掉这些由使用方式决定的资源。

认证月活也不能直接代替在线连接数。一个用户在同月多次进入应用，与更多不同用户在同月使用应用，是不同的增长情形；多人同时在线收消息，又会抬高实时连接与分发需求。建模时至少要分别记录月活、每日历史消息读取、每条新消息的在线接收人数、连接峰值、附件保存量和下载量。

免费额度与付费起点如何对齐

按Supabase 官方价目，Free 包含每月 5 万认证月活、每项目 500 MB 数据库、5 GB 传出流量和 1 GB 文件存储，闲置项目可能暂停；Pro 从每月 25 美元起，包含 10 万认证月活、每项目 8 GB 数据库磁盘、250 GB 传出流量、100 GB 文件存储、500 个实时峰值连接和每月 500 万条实时消息，付费套餐另有每月 10 美元计算额度，可覆盖一个 Micro 实例。Pro 的起价因此不是任意负载下的固定总额：增加项目、提高计算规格或超出资源配额，都可能增加费用。

按Firebase 官方价目，Cloud Firestore 标准版的免费额度包括每天 5 万次文档读取、2 万次写入、2 万次删除，以及 1 GiB 数据存储和每月 10 GiB 网络传出。Authentication、Cloud Storage 和 SQL Connect 则按各自条件计算；存储桶类型与所用服务会影响附件账单。每日操作额度按天计算，访问高峰不能借用前一天未用完的额度。

这两套价格不能直接相减。Supabase 的套餐把月活、容量、传出和实时配额放在一起，并另计超额用量；Firestore 的文档操作随访问次数变化，存储和网络也另有计量。原型阶段两者都可能便宜，正式运营后谁的账单先上升，取决于应用实际消耗了哪一项资源。

同一聊天应用，读取增加后账单怎样变化

设一个纯属演算的场景：每天有 1 万名活跃用户，每人发送 5 条消息、读取 20 条历史消息；每条新消息平均再被一名在线用户通过监听读到。假定一条消息对应一个文档，历史读取已包含监听开始时取得的文档，每天用量均匀，一个月按 30 天计算，便得到每月 150 万次写入和 750 万次读取。扣除每日免费额度，付费部分为 90 万次写入和 600 万次读取。

Firestore 标准版计费说明以 us-central1 为例，列出每百万次文档读取 0.30 美元、每百万次写入 0.90 美元，并说明监听结果中新加入或更新的文档按读取计费。按上述假设，文档读写费约为 2.61 美元；这尚未计入数据与索引占用、可能产生的索引读取、网络传出、附件及其他服务。

若发消息人数和频率不变，只把每人每天读取的历史消息从 20 条提高到 300 条，月读取量就变成约 9150 万次。沿用同一免费额度和示例单价，文档读写费约为 27.81 美元，已高于 Supabase Pro 的标称起价。但这不能直接推出 Supabase 总账单更低：基础计算配置是否足以承担负载，以及连接、实时消息和传出流量是否留在套餐内，仍取决于实际部署。

另一种增长是历史消息读取不多，但每条新消息同时送达更多在线成员。Firestore 可能因此产生更多监听读取；Supabase 则可能先碰到实时消息量或峰值连接限制。若附件下载随成员数一同增长，两边还要分别核算文件传出。账单出现反转时，通常是某项使用行为跨过了配额或计量门槛，而非月活这一个数字突然改变了平台优劣。

什么时候值得选择自托管

如果团队需要控制部署环境和数据运维路径，Supabase 提供自托管选择。Supabase 自托管说明将服务器维护、安全更新、PostgreSQL 运维、备份、容灾和监控列为团队责任，并列出部分托管功能在自托管时不可用。自托管能改变控制权和成本结构，但不能把这些工作视为免费。

对缺少专职运维的小团队，先按托管方案估算更能反映日常投入。若聊天产品将持续增加跨实体查询、细致权限和迁移需求，Supabase 的关系型路线更容易保持数据模型清晰；若主要挑战是移动端实时与离线同步，Cloud Firestore 更省客户端同步工程。决定增长后费用的，是用户读了多少旧消息、新消息送给多少在线成员，以及附件实际传出了多少数据。