Supabase vs Firebase：我选择的原因

Source: Dev.to

作为独立开发者的需求

• 快速 MVP 开发
• 关系型数据建模
• SQL 灵活性
• 干净的认证 + 基于角色的访问控制
• 开源友好的技术栈
• 可预测的定价

快速对比概览

为什么 Firebase 很棒（以及我为何没有选择它）

Firebase 的优势

• 极快的搭建速度
• 出色的实时功能
• 坚如磐石的基础设施
• 成熟的生态系统

Firebase 不适合我的地方

大规模时的 NoSQL 复杂度

起初简单，但复杂关系（例如，用户 → 帖子 → 评论 → 点赞）很快变得尴尬。

查询限制

Firestore 查询常常需要：

• 预先规划的索引
• 数据重复
• 对基本连接的变通方案

供应商锁定

你的数据模型会紧密耦合到 Firebase 的使用模式。

不可预测的成本

读取量快速增长——账单增长更快。

Firebase 适用于： 实时应用、聊天系统以及数据结构扁平的中小型产品，但它不符合我的长期愿景。

为什么我选择了 Supabase

PostgreSQL（这才是决定性因素）

SQL 具备：

• 可预测性
• 强大功能
• 经受考验

连接、约束、视图、触发器——一切都能正常工作。例如：

SELECT users.name, posts.title
FROM users
JOIN posts ON users.id = posts.user_id;

Supabase 对熟悉关系查询的人来说非常自然。

内置认证且不与之冲突

Supabase Auth 支持：

• 邮箱/密码
• OAuth 提供商
• 行级安全（RLS）

权限可以在数据库层面强制，而不仅仅在应用代码中实现——这对安全性和清晰度是巨大的优势。

行级安全（RLS）

RLS 让我可以定义规则，例如：

• 用户只能读取自己的数据
• 管理员可以查看所有数据
• 公共数据无需认证即可读取

这大幅降低了后端的复杂度。

开源且锁定更少

Supabase 是：

• 开源的
• 基于 PostgreSQL
• 可迁移的

即使以后离开 Supabase，我的数据仍然是标准的 SQL，令人安心。

可预测的定价

Supabase 的定价更容易理解（存储、请求、带宽），因此我不必担心意外账单。

何时 Firebase 可能是更好的选择

• 需要在大规模下进行实时同步
• 数据模型简单
• 更看重速度而非灵活性
• 正在构建原型或黑客马拉松项目

Firebase 并非“糟糕”；它针对的是不同的问题而优化。

最终结论

我选择 Supabase，因为：

• SQL 更适合我的产品扩展
• RLS 简化了安全管理
• PostgreSQL 让我的数据具备未来保障
• 开源降低了长期风险

如果你思考的是表、关系和约束，Supabase 会让你有归属感。如果你思考的是文档和实时流，Firebase 可能更适合你。

我的建议

不要盲目追随 hype。应基于以下因素做出选择：

• 你的数据模型
• 你的增长计划
• 你对锁定的容忍度

你选择了哪一个——Supabase 还是 Firebase？我很想知道是什么让你倾向于某一方。