11.3 万星之后，Supabase 想让 AI 应用直接长在 Postgres 上

本文基于 GitHub 项目 supabase/supabase 的 README 整理。

摘要：Supabase 今天再收 504 星，以 113,041 颗星坐稳开源 BaaS 头把交椅。它的策略从来没变过：把 Firebase 的每个功能拆开，用成熟的开源件重新拼一遍，再挂到同一个 Postgres 上。

---

Supabase 的 README 首页是一串打满勾的清单。这份清单本身就是它的产品哲学——Firebase 有什么，它就补一个开源实现；市面已有成熟开源件的，直接集成；没有的，自己写一个并开源。

截至今日，这个项目在 GitHub 上拿到 113,041 颗星，单日新增 504 星，仍是 Trending 榜单上的常客。

一张全打勾的功能清单

README 列出的能力，每一项都已可用：

• 托管的 Postgres 数据库
• 认证与授权
• 自动生成的 API：REST、GraphQL、Realtime 订阅
• 函数：数据库函数、Edge Functions
• 文件存储
• AI + 向量/嵌入工具包
• Dashboard

作者对这套组合的定位说得很清楚：不是 Firebase 的一比一映射，而是”用开源工具给出 Firebase 式的开发者体验”。选择工具的标准也写在 README 里——只要社区存在、且是 MIT、Apache 2.0 或同等宽松许可的项目，就直接用并支持它。

拆开看：五个成熟件拼成一套平台

Supabase 的架构并不神秘，全是经过时间验证的组件：

• Postgres：30 多年持续开发的对象关系数据库，可靠性和功能完备性是它的招牌。
• Realtime：一个 Elixir 服务，轮询 Postgres 内置的复制功能，把插入、更新、删除转成 JSON，再通过 websocket 广播给已授权的客户端。
• PostgREST：把 PostgreSQL 数据库直接变成 RESTful API 的 Web 服务器。
• GoTrue：基于 JWT 的认证 API，处理注册、登录和会话管理。
• Storage API：文件存储服务。

这套拆法的好处在于，每一层都是独立可替换的。你不用接受整包，也能只取认证或只取实时订阅。

为什么 AI 应用会往这里靠

近两年新增的那一勾很关键：AI + 向量/嵌入工具包。

AI 应用的数据需求其实和传统 BaaS 高度重叠——要有向量检索、要多租户隔离、要实时协作、要有对象存储放文档和图片、要能跑边缘函数做推理前后的处理。这些能力 Supabase 原本就有，补上 pgvector 生态之后，”把 AI 应用的数据层放在一个 Postgres 实例里”就成了一个可选项，而不是必须拼三个云服务。

对不想被单一云厂商锁定的团队，这一点吸引力不小：数据库是 Postgres，随时可以 pg_dump 走人；认证、存储、实时都是独立开源服务，自托管也有完整路径。

三种用法，从一分钟到全自建

README 明确了三条路：

1. 云端托管：在 supabase.com 注册，一分钟内起一个工作区，不管理任何基础设施，版本始终最新。
2. 自托管：用官方文档里的部署方案把整套栈跑在自己的机器或云上。
3. 本地开发：本地起一套用于开发的实例，配合 CLI 做迁移和调试。

社区入口也算齐：GitHub Discussions 适合建站求助和数据库最佳实践讨论，Issues 报 bug，邮件支持处理数据库和基础设施层面的问题，Discord 用来晒作品和闲聊。README 还提醒可以 watch 这个仓库来接收大版本更新通知。

值得注意的地方

Supabase 不是”零成本的 Firebase”。它把复杂度从”厂商黑盒”转移到了”你需要懂一点 Postgres”——RLS（行级安全）、索引、连接池这些概念绕不过去。反过来说，愿意学这些的团队换来的是可迁移、可审计、可自托管。

对一个还在选型的项目来说，判断标准很简单：如果你预计数据层会长期是核心资产、且不希望它被某家云绑定，Supabase 的组合式路线比一体化 BaaS 更稳；如果你只想两周内上线一个 MVP 且完全不想碰数据库，那一体化托管服务依然更省心。

项目地址：https://github.com/supabase/supabase

🔁 重复度：低 — 未检索到 Supabase 的同项目既往报道，可正常发布