Supabase:开源版 Firebase 的七年答卷,把 Postgres 变成全栈开发平台
posts posts 2026-09-20T04:25:00+08:00Supabase 是 11 万 Star 的开源 Postgres 开发平台,围绕数据库组装认证、自动 API、实时订阅、边缘函数与向量工具链。本文拆解其组合开源工具的架构策略、模块化客户端设计与自托管路径。技术笔记Supabase, PostgreSQL, 后端, 开源, BaaSSupabase:开源版 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 API | postgrest.org 开源项目 |
| GoTrue | 基于 JWT 的认证:注册、登录、会话管理 | Supabase 自研开源 |
| Realtime | 用 WebSocket 监听 Postgres 增删改 | Elixir 服务,轮询 Postgres 内建复制功能 |
| pg_graphql | GraphQL API | Postgres 扩展 |
| Storage | S3 上的文件管理,权限走 Postgres | Supabase 自研 REST API |
| postgres-meta | 管理 Postgres 本身(建表、角色、查询) | Supabase 自研 REST API |
外层由 Envoy(云原生边缘代理)统一网关。每个组件是独立进程,独立仓库,Supabase 平台做的是把它们编排成一致的开发者体验:Dashboard 控制台、自动生成的 API、统一的客户端库。
这张表里藏着一个关键设计:权限模型单一化。Storage 的文件权限、Realtime 的订阅授权、PostgREST 的行级安全(Row Level Security)全部回落到 Postgres 本身的权限体系。学会一套 Postgres 权限,就学会了整个平台的访问控制。
一个任务如何流过系统
以"前端订阅某张表的新增记录并实时展示"为例:
- 前端用
supabase-js的auth模块通过 GoTrue 登录,拿到 JWT - 建立 WebSocket 连接到 Realtime 服务,订阅目标表
- 有新行写入 Postgres 时,Realtime 通过 Postgres 内建的复制机制轮询到变更
- 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 登录。欢迎补充事实、异议与实践。
讨论暂时无法加载。