跳到正文

目录

Supabase:开源版 Firebase 的七年答卷,把 Postgres 变成全栈开发平台

Supabase:开源版 Firebase 的七年答卷

Supabase 常被一句话介绍为"开源版 Firebase",但这个说法只说对了一半。Firebase 的核心是 Google 云上的封闭服务集合;Supabase 的核心是一个专属于你的 Postgres 数据库,认证、API、实时订阅、文件存储、边缘函数、向量检索全部围绕这个数据库组装。项目 2019 年创建,Apache 2.0 协议,主仓库 TypeScript 为主,如今约 11 万 Star——它给出的答卷是:用企业级开源工具拼出 Firebase 级的开发体验,且每一个组件都可以自托管。

先给判断

Supabase 最值得学的不是功能清单,而是一条工程原则:能用现成开源工具就绝不重造,造出来的也全部开源。README 原文写得很直白——如果社区已有 MIT/Apache 级协议的成熟工具,就直接用;如果没有,他们自己造然后开源。这条原则决定了它的架构形态:Supabase 不是单体应用,而是七八个独立开源项目的编排层。带来的直接好处是无锁定:哪天不想用 Supabase 平台了,底下的 Postgres、PostgREST 都是标准组件,数据和行为都跟得走。

系统地图:一个数据库,七件工具

组件职责本体
Postgres数据库本体,30 余年的对象关系数据库PostgreSQL
PostgREST把数据库直接变成 RESTful APIpostgrest.org 开源项目
GoTrue基于 JWT 的认证:注册、登录、会话管理Supabase 自研开源
Realtime用 WebSocket 监听 Postgres 增删改Elixir 服务,轮询 Postgres 内建复制功能
pg_graphqlGraphQL APIPostgres 扩展
StorageS3 上的文件管理,权限走 PostgresSupabase 自研 REST API
postgres-meta管理 Postgres 本身(建表、角色、查询)Supabase 自研 REST API

外层由 Envoy(云原生边缘代理)统一网关。每个组件是独立进程,独立仓库,Supabase 平台做的是把它们编排成一致的开发者体验:Dashboard 控制台、自动生成的 API、统一的客户端库。

这张表里藏着一个关键设计:权限模型单一化。Storage 的文件权限、Realtime 的订阅授权、PostgREST 的行级安全(Row Level Security)全部回落到 Postgres 本身的权限体系。学会一套 Postgres 权限,就学会了整个平台的访问控制。

一个任务如何流过系统

以"前端订阅某张表的新增记录并实时展示"为例:

  1. 前端用 supabase-jsauth 模块通过 GoTrue 登录,拿到 JWT
  2. 建立 WebSocket 连接到 Realtime 服务,订阅目标表
  3. 有新行写入 Postgres 时,Realtime 通过 Postgres 内建的复制机制轮询到变更
  4. Realtime 把变更转成 JSON,经授权校验(该客户端的 JWT 有没有权限看到这条变更)后,通过 WebSocket 广播给客户端

注意第 4 步:授权不是应用层自己写的 if-else,而是复用 Postgres 权限。这是"单一权限模型"落到实处的样子。

客户端的模块化设计

Supabase 官方客户端覆盖 TypeScript、Flutter、Swift、Python 四语言,社区维护 C#、Kotlin、Go、Rust、Ruby、Godot 等。值得看的设计是每个子客户端都是独立实现:supabase-js 内部由 postgrest-js、auth-js、realtime-js、storage-js、functions-js 五个独立包组成,主包只是聚合。这意味着你可以在任何项目里单独用 postgrest-js 操作 PostgREST,不必引入整套 Supabase 运行时——“支持现有工具"这条原则在客户端层同样成立。

部署路径:三种选择

  • 托管平台:supabase.com 注册即用,零安装
  • 自托管:官方提供 self-host 文档,所有组件开源意味着整套栈可以搬进自己的机房
  • 本地开发supabase cli 支持本地起完整环境开发,与云端结构一致

对数据合规敏感的团队,“云端开发体验 + 数据不出内网"两者兼得,是 Supabase 相对 Firebase 的结构性优势。

适用边界

适合谁:前端/移动团队想快速搭建带认证和实时能力的全栈应用,又不想被云厂商锁定;已经熟悉 Postgres 的团队上手成本尤其低——你积累的 Postgres 技能(RLS、触发器、函数)全部直接可用,包括 pgvector 做的 AI 向量工具链。

不适合谁:需要 Firebase 那种全球化边缘节点实时同步(Firestore 的多区域冲突消解)的场景——Supabase 的实时能力建立在单库复制上,跨区域扩展是另一套问题;重度依赖非关系模型(宽列、文档型灵活 schema)的场景,Postgres 的 JSONB 能做但不是它的主场。

采用顺序建议:从托管平台免费档起步,用 Dashboard 建表试 API 和 Auth,跑通后再决定是否 self-host——先体验它对开发效率的提升,再权衡运维成本。

结语

Supabase 证明了 BaaS(Backend as a Service)可以建立在完全开源的栈上而不牺牲开发体验。它对开发者的最大承诺不是功能多,而是你的数据住在你信得过的数据库里——对一个 2019 年才起步的项目,11 万 Star 是市场对这条路线的投票。

项目地址:supabase/supabase,文档 supabase.com/docs

参与讨论

使用 GitHub 登录。欢迎补充事实、异议与实践。