Supabase：以 Postgres 为内核的开源 Firebase 替代平台

过去十多年，移动应用和 Web 应用的后端越来越像一套固定的套餐：数据库、用户登录、文件存储、实时推送、服务端函数。Firebase 把这套东西打包成托管服务，让前端开发者几乎不用碰服务器就能把产品推上线，但代价是数据模型被锁在专有体系里，想迁移或自托管都很困难。Supabase 正是从这个痛点出发的。它自称是 Postgres 开发平台，目标是用企业级的开源工具，做出 Firebase 那样顺手的开发体验。项目的原则写得很直白：如果某个工具已经存在，并且采用 MIT、Apache 2 或同等宽松的开源许可证，就直接采用并支持它；如果这样的工具不存在，就自己动手做出来并开源。所以 Supabase 并不是对 Firebase 的一比一复刻，而是一个把成熟开源组件拼装成统一产品的平台。它的核心是一台专属的 Postgres 数据库，这套对象关系数据库系统已有三十多年的持续开发历史，在可靠性、功能完整度和性能上口碑稳固。围绕这台数据库，Supabase 提供托管数据库、认证与授权、自动生成的 API、函数、文件存储、AI 向量工具包和管理面板。仓库在 GitHub 上已有十一万多颗星，主要用 TypeScript 编写，话题标签涵盖 ai、auth、database、deno、embeddings、firebase 等，说明它同时占据了 Firebase 替代品和 AI 应用数据层两个位置。Supabase 的技术价值主要体现在组件的组合方式上。数据库层是 Postgres，所有数据和权限最终都落在这里。

PostgREST 是一个 Web 服务器，能把 Postgres 数据库直接变成 RESTful API，所以表建好之后接口就自动出现，不必再手写一层增删改查代码。pg_graphql 是一个 PostgreSQL 扩展，为同一份数据提供 GraphQL 接口，让团队可以按习惯选择查询方式。Realtime 是一个用 Elixir 编写的服务器，通过 websocket 监听 Postgres 的插入、更新和删除：它读取 Postgres 内置的复制功能获得数据变化，把变化转换成 JSON，再广播给已获授权的客户端。认证部分由 GoTrue 承担，这是一套基于 JWT 的认证 API，负责用户注册、登录和会话管理。Storage 是一个管理 S3 文件的 RESTful API，而权限交给 Postgres 处理，因此文件和数据行可以共用同一套授权逻辑。函数分为两类，一类是数据库函数，另一类是 Edge Functions，话题标签里的 deno 也暗示了后者与 Deno 运行时的关系。此外还有 AI 与向量嵌入工具包，让 Postgres 同时承担关系数据和 embeddings 的存储。与 Firebase 的专有文档数据库相比，最大的差别是底座：这里是标准 SQL 加开放组件，每一块都可以单独检查、替换和理解。从上手路径看，Supabase 给了三种选择。最省事的是直接使用托管平台：在 Dashboard 注册，不需要安装任何东西就能开始用。想要更多控制权的团队，可以按官方的托管指南自行部署，也可以在本地搭建开发环境，把数据库、认证、存储这一整套服务跑在自己的机器上。

典型的使用方式是先在 Postgres 里设计表结构，再由系统自动生成 REST、GraphQL 和实时订阅接口，前端应用直接调用，登录与文件上传则交给内置的认证和存储服务；需要自定义逻辑时，再写数据库函数或 Edge Functions。做 AI 应用的开发者，可以把向量数据和业务数据放进同一个数据库，省去单独维护向量库的麻烦。文档集中在 supabase.com/docs，按数据库、认证、API、GraphQL、实时、函数、存储和 AI 分成独立的指南，对应 README 里的功能清单。社区渠道也分工明确：GitHub Discussions 适合讨论构建问题和数据库最佳实践，GitHub Issues 用来报告缺陷，邮件支持处理数据库或基础设施问题，Discord 则用于交流作品。想参与贡献的人可以先读 DEVELOPERS.md，关注仓库的 releases 就能得知重要更新。对工程团队来说，Supabase 的意义在于把「快速起步」和「不被锁定」放进了同一个方案。它选择让 Postgres 站在中心，意味着数据结构、查询语言和权限模型都是行业通用知识，团队今天积累的经验，明天换一套基础设施时仍然有用。在 AI 应用兴起的背景下，把向量与 embeddings 放进关系数据库，也让小团队能用更少的系统完成原型到上线。当然，也有几点值得保持清醒。第一，Supabase 是由多个独立开源组件拼成的平台，自托管时需要理解并运维这些部件，工作量取决于团队规模和经验。第二，它强调自己不是 Firebase 的一比一映射，从 Firebase 迁移的团队需要重新理解数据建模和权限设计，尤其要认真学习 Postgres 本身。第三，依赖托管服务和依赖开源自建之间的取舍，需要结合成本、合规和运维能力来评估。接下来值得观察的方向包括：AI 与向量工具包能否在更大规模的真实场景里站稳，Edge Functions 的开发体验如何演进，以及这套开源组合在社区贡献的推动下，能否继续保持各组件之间的协同与稳定。