它一开始的自我介绍是"Firebase 的开源替代"。但 2026 年，给它写数据库的人，越来越多不是人类。
2011 年 Firebase 上线，做的事情很干脆：把后端从创业公司的任务清单上划掉。注册登录、数据库、文件存储、推送，一个控制台搞定。开发者只写前端，剩下的交给它。
十年下来，这套模式被验证了。也被抱怨了。
抱怨集中在两点。第一，Firestore 是文档型数据库，不是关系型。数据一旦需要多表关联、需要复杂事务，你就得在应用层自己算，算着算着代码就乱了。第二，它闭源。你可以用，但不能带走，也不能自己部署一份。
2020 年，两个人决定按另一个思路重做一遍这件事。Paul Copplestone 和 Ant Wilson 开源了一个项目，叫 Supabase。它不自己造数据库，而是把已有三十多年历史的 PostgreSQL 摆在正中间，再把认证、存储、函数、实时这些能力一块块拼上去。
接下来的五年，它长成了一个注册开发者超过 1000 万的平台。而故事真正的转折出现在最近两年：给它建数据库的"人"，越来越多是 AI 编码代理。
这篇文章想回答的，就是这条线上的五个问题：它到底是什么、由什么组成、比对手好在哪、要花多少钱、以及为什么偏偏是它被 AI 选中。
一句话：它卖的不是数据库，是一整套"开箱即用的后端"。
先看官方给自己的定义。Supabase 现在的自我介绍是 "The Postgres Development Platform"——Postgres 开发平台的身份，比"Firebase 替代"更准确。
关键在于那个"不自己造"。数据库是现成的 PostgreSQL，Supabase 做的是两件事：一是把它托管好，二是围着它补齐后端需要的一切。
为什么是 Postgres，而不是像 Firebase 那样重做一套？
因为 Postgres 是一个已经赢了三十年的东西。它有关系模型、有 ACID 事务、有 SQL 这门所有开发者都会的语言，更关键的是——它有扩展生态。向量检索靠 pgvector，全文检索靠内置能力，外部数据源靠 FDW。这些能力不用 Supabase 自己发明，社区早就写好了。
对比一下就很清楚。Firebase 的短板，正好是 Postgres 的长板：数据关系复杂时，SQL 表达起来是几行查询；同样的逻辑在文档型数据库里，是一堆应用层代码。
再看这门生意的体量。
| 维度 | 数据 | 口径 |
|---|---|---|
| 注册开发者 | 1000 万+ | 官网公司页 |
| GitHub Star | 10 万+ | 官网公司页；2025 年度总结口径为 9.5 万 |
| 累计融资 | 约 10 亿美元 | 官网公司页 |
| 最新估值 | 105 亿美元（投后） | Series F，2026-06-04 |
值得留意最后一行。105 亿美元这个数字，来自 2026 年 6 月的一笔 5 亿美元融资，领投方是新加坡主权基金 GIC。一年多以前，它的估值还是 20 亿。
那这五年它到底往 Postgres 上拼了些什么？
官方叫它"可组合的后端栈"。拆开看，每一块都对应一个开发者过去要自己搭的东西。
每个项目一个独立的 Postgres 实例，不共享。建表之后自动生成 REST 和 GraphQL 接口，前端可以直连，不需要自己写一层 API。
这里的核心武器是 Row Level Security（行级安全，RLS）。它把权限规则写进数据库：这条数据谁能读、谁能写，定义在表上，而不是散落在后端代码里。前端拿到的密钥是受限的，越权请求在数据库这一层就被拦下。
再加两个工程细节：Dedicated Poolers 解决连接数问题——Serverless 场景下函数会疯狂建连接，把 Postgres 拖死；声明式 Schema 让你用配置文件描述表结构，可以进 Git。
邮箱密码、社交 OAuth、匿名登录、多因素认证、企业级 SSO（SAML），一整套。它还能签发 JWT，和 RLS 直接打通——用户一登录，数据库就知道他是谁。
2025 年之后还加了两个不太常见的：第三方认证服务托管（把 Firebase、Clerk、Cognito 的用户迁过来），以及 Solana / Ethereum 钱包登录。
S3 兼容的对象存储，管图片、视频、文件。自带 CDN 和图片实时转换（不用自己起一个压缩服务），单文件上限提到 500GB。权限同样走 RLS 那套逻辑。
基于 Deno 的 TypeScript 函数，部署在全球边缘节点。适合放那些不该进数据库的逻辑：调用第三方支付、发邮件、处理 Webhook。
基于 Postgres 的复制机制做实时推送。数据库里的一行变了，订阅它的前端立刻收到。支持广播和变更推送，2025 年底还补了一项 Realtime Replay，可以回放一段时间内的事件——断线重连之后不会丢状态。
通过 pgvector 扩展做向量存储和语义检索。这是它近两年增长最快的一块，因为 RAG 应用需要的东西，恰恰就是"一个数据库同时存业务数据和向量数据"。2025 年底又加了 Vector Buckets 和基于 Iceberg 的 Analytics Buckets。
再说一个具体的体验。装好命令行工具之后，敲一条 supabase start，本地会拉起一整套环境：数据库跑在 54322 端口，API 在 54321，管理界面 Studio 在 54323。打开浏览器就是完整的控制台，可以建表、看数据、调 Auth。整个过程不需要一个云上账号。
这套东西拼在一起，才是它真正的卖点——不是某一块特别强，而是它们本来就长在一起。
三个最常被拿来比的：Firebase、Neon、Appwrite。
先说结论：这三家和它争的其实不是同一个位置。
| 对比项 | Supabase | Firebase | Neon |
|---|---|---|---|
| 数据模型 | 关系型 Postgres | NoSQL 文档 | 关系型 Postgres |
| 查询语言 | SQL + 自动 REST/GraphQL | 受限的 SDK 查询 | SQL |
| 业务模块 | Auth / Storage / 函数 / 实时 全含 | 齐全 | 只有数据库 |
| 开源 | 是，可自托管 | 闭源 | 部分开源 |
| 权限模型 | 数据库层 RLS | 安全规则 + 后端代码 | 数据库角色 |
| 成本可预测性 | 较可控 | 读次数计费，易失控 | 按计算单元 |
对 Firebase：这是路线之争。Firebase 的优势在实时同步和极低的上手门槛，免费额度也慷慨。但它的数据模型是文档型，复杂关系要靠应用层硬凑；它是闭源的，你没法自己部署一份。Supabase 反过来：门槛略高，但拿到的是关系模型、事务和可迁移性。
有一个历史细节值得记住：Firebase 曾经也基于 Postgres 做过实验，收购了 Parse 之后还开源过一部分。但最终没走下去。Supabase 赌的方向，正是它中途放弃的那条。
对 Neon：它们的数据库是同一款，差别在层的厚度。Neon 是带分支能力的 Serverless Postgres，做得很好。但它只有数据库——认证、存储、边缘函数、实时推送，这些都得你自己找别的服务拼。Supabase 的价值就在这一层："一个项目里，这些东西都配齐了。"
对 Appwrite：开源这件事上两家是一致的。Appwrite 强调自托管的自由度，数据层支持 SQL 和 NoSQL；Supabase 更强调"托管的和本地的跑同一套代码"，以及完整借力 Postgres 生态。选哪个，取决于你是更想贴近 Postgres 的生态，还是更想贴近一套自成一体的 API。
如果只能记一句话：Supabase 最难被替代的地方，是它把 RLS 放在了正中间。权限定义在数据旁边，前端可以安全地直连数据库。这个设计决定了它的整套架构长什么样。
这块的答案比大多数人想的要实在。
先把四个档位摆出来。
| 套餐 | 价格 | 关键额度 |
|---|---|---|
| Free | 0 美元 / 月 | API 请求不限量；5 万月活用户；500MB 数据库；1GB 文件存储；5GB 出口流量 |
| Pro | 25 美元 / 月起 | 10 万月活；8GB 磁盘 / 项目；100GB 文件存储；250GB 出口流量；7 天备份 |
| Team | 599 美元 / 月起 | Pro 全部能力 + SOC 2 / ISO 27001、SSO、项目级权限、14 天备份 |
| Enterprise | 定制 | 专属支持、Uptime SLA、AWS PrivateLink、7×24 支持 |
三个容易被忽略的点，比价格本身更重要。
这是整篇文章里最值得注意的部分。因为它解释了那笔 5 亿美元的融资。
先把时间线摆出来。
2025 年 3 月，Supabase 发布了 MCP Server。MCP 是一个让 AI 助手连接外部工具的协议，而 Supabase 提供的那套连接，允许 Agent 直接读数据库结构、执行查询、创建迁移。
这件事听起来技术性很强，但实际体验很朴素。假设你在 Cursor 里说一句"给 users 表加一个 last_login 字段"——Agent 不再需要你复制粘贴 SQL，它自己调用工具，生成迁移文件、应用到数据库、把结果读回来。
到 2025 年 10 月，它又补上了 Remote MCP Server，不用在本地起服务也能连。年底那波发布里，还有 Vector Buckets 和 OAuth2 Provider。
然后是估值。
| 轮次 | 时间 | 金额 | 投后估值 | 领投 |
|---|---|---|---|---|
| Series D | 2025-04 | 2 亿美元 | 20 亿美元 | Accel |
| Series E | 2025-10 | 1 亿美元 | 50 亿美元 | Accel、Peak XV |
| Series F | 2026-06-04 | 5 亿美元 | 105 亿美元 | GIC |
一年多时间，估值从 20 亿涨到 105 亿。融资公告里的说法是"加速在 Agentic Infrastructure 上的领先"，措辞很直白——它现在卖的身份，是"AI 代理的基础设施"，而不是"Firebase 替代品"。
为什么 Agent 会挑中它？回头看其实不难理解。
外部分析提到了一个更尖锐的说法：AI 编码代理已经成为 Supabase 平台上新建数据库的主要来源，其中 Claude Code 是最大的贡献者。如果这个判断成立，那意味着它的用户增长曲线，已经开始由机器而不是人来推动了。
看几个具体的。
Mozilla。用它搭建生成式 AI 和 RAG 应用。这个组合恰好对应前面说的那一点：向量和业务数据在同一个 Postgres 里。
eXp Realty。这家房产经纪公司用 Auth、数据库、边缘函数和实时推送，自建了一个叫 "The Hub" 的社区平台，替代掉了一批原本外购的 SaaS。这里的价值不在省了多少钱，在于数据回到了自己手里。
Shotgun。迁移之后成本下降了 83%。这个数字的来源是官方客户案例。
Maergo。用它扛住过 100 倍的流量峰值。
Voypost。官方口径是开发效率提升了 20%。
把这几个案例放在一起，能看到一条共同的线索：选择它的理由，几乎都不是"功能比其他家多"，而是"某一个具体问题解决了"。Shotgun 解决的是账单，Maergo 解决的是峰值，eXp Realty 解决的是数据自主权。
行业分布上，官网的客户名单明显偏向金融科技、AI/ML、SaaS 和专业服务。这个分布和它的技术特点吻合——越是数据关系复杂、越是需要细粒度权限的场景，越容易吃到 RLS 的甜头。
回到开头那个问题。
2020 年它的开局逻辑是"用开源重做 Firebase"。这个逻辑今天仍然成立，但它已经不是这个故事的重点了。
真正的赌注在另一件事上：它赌的是"后端这层不应该被封装成黑盒"。
Firebase 把后端变成了一组 SDK 调用，用起来舒服，代价是你看不见里面。Supabase 把后端还原成数据和规则——一张表、一条 SQL、一段 RLS 策略。对人来说，这需要多学一点东西；但对 Agent 来说，这恰好是它唯一能操作的形式。
所以那笔 5 亿美元，买的不是数据库市场。
留一个实在的问题：当你团队里的代码有一半是 AI 写的，你希望它面对的是一个黑盒，还是一张能读能改能进 Git 的表？这个问题的答案，正在决定下一批后端工具的形状。