Supabase 解剖：9 万 star 是旧闻，一周一百万个数据库才是新闻
先对个账。素材说 Supabase 在 GitHub 有 9 万 star。我们抓了 GitHub API：111,076，2026 年 10 月 4 日实测。9 万是去年的快照——今年 4 月过 10 万，现在 11.1 万，fork 1.5 万，贡献者 4 月口径 1893 人。仓库 2019 年 10 月建，七…
先对个账。素材说 Supabase 在 GitHub 有 9 万 star。我们抓了 GitHub API：111,076，2026 年 10 月 4 日实测。9 万是去年的快照——今年 4 月过 10 万，现在 11.1 万，fork 1.5 万，贡献者 4 月口径 1893 人。仓库 2019 年 10 月建，七岁，Apache 2.0。
但 star 数不是这个项目最大的故事。最大的故事藏在它改掉的自我介绍里。
一句 slogan 的退役
2020 年出道时，Supabase 的官方定位是「开源 Firebase 替代品」。Firebase 是 Google 的后端全家桶，开发者嫌它锁定、嫌它自家 NoSQL。Supabase 说：同样是开箱即用的后端，我用 Postgres，协议开放，随时搬走。借势打法，聪明。
现在去仓库首页看，那句话没了。取而代之的是「The Postgres development platform」——Postgres 开发平台。Firebase 不再是它的参照系，对比文里反而成了被比较的一方。2026 年 9 月一篇格局总结说得很整齐：Firebase 占移动端，Supabase 占 SQL 优先的 Web SaaS，Neon 占 serverless Postgres，Appwrite 占自托管。
替代品做大了，就把名字里的「替代」摘了。这是所有借势叙事的终点：参照物变成了同侪。
它到底封装了什么
回到 BaaS 本身。Supabase 的封装思路值得单说，因为它几乎不造轮子。
数据库是 Postgres 本尊，每个项目一个专属实例。REST API 靠 PostgREST，一个有十年历史的 Haskell 独立项目，把任意 PG 库自动变成 API。认证用 GoTrue，Netlify 的开源项目改造。实时推送是 Elixir 写的 Realtime 服务，监听 PG 自带的复制流，把每一行的增删改转成 websocket 消息。文件存储对接 S3 兼容对象存储。边缘函数引擎 Edge Runtime 是 Rust 写的，内核是 Deno，跑 TypeScript 和 WASM。
组合拳的哲学一句话：Postgres 生态里能找到的，就不重写。「强大的 PostgreSQL 基础」不是营销话术，是整个架构的承重墙——数据不存私有格式，就是一张张标准 PG 表。这是它和 Firebase 最大的区别，也是「随时搬走」承诺的技术底气。
为什么是 2025
火需要配方。2025 年的配方是：AI 把写前端的成本打穿了。Lovable、Bolt.new、v0、Cursor，输入一句话出一个应用界面。前端免费了，后端成了瓶颈——界面背后总得有登录、有数据库、有文件上传，手工搭一套要几天，AI 应用等不起。
Supabase 接住了。这些 AI 建站工具几乎全接了 Supabase 一键集成。AI 生成前端，Supabase 兜后端，从想法到上线不写一行后端代码。这个组合在 2025 年成了标准配方。
账本跟着走：2025 年 10 月 E 轮，1 亿美元，Accel 和 Peak XV 领投，估值 50 亿。九个月后的 2026 年 6 月 4 日，F 轮，5 亿美元，新加坡主权基金 GIC 领投、Stripe 跟投，投后 105 亿。官方口径近 1000 万开发者。开源项目拿主权基金的钱，不多见。
客户换人了
F 轮报道里最有信息量的一句话来自一家创业媒体：AI agent，尤其是 Claude Code，现在部署了 Supabase 上大多数数据库。CEO Copplestone 在公开访谈里给过一个更狠的数字：每周新部署超过 100 万个 Postgres 数据库，手工建的趋近于零（访谈口径，单源，留意）。
这句话值得停下来想十秒。数据库过去是「项目」的标配，一个项目一个库，建库是开工仪式。现在建库的单位变成了 agent 会话：agent 接到需求，起一个库，跑起来，会话结束，库留下或者丢掉。一周一百万个，基建变成消耗品。
F 轮那周的报道标题说得更直白——On Supabase, the customer is now an agent。客户不再是开发者，是替开发者干活的 agent。
反方证据照例上台
37 小时。2026 年 8 月 Hacker News 一个帖子：一家公司的生产库因为一次计费错误停了 37 小时，没有自助恢复选项，不能重启不能还原。单方说法，没法核实，但底下共鸣不少。规模上来之后，运维短板开始暴露。
第二笔账是代码质量。vibe coding 社区有个高频提醒：AI 生成的应用里，auth 是最容易静默出错的环节——能跑，但权限模型可能是错的。Supabase 的行级安全（RLS）把权限策略写在数据库层，每行数据都受策略约束，这是好设计，但前提是策略写对了。AI 很会建表，不很会写 RLS 策略。权限声明和行级强制之间的这道缝，是下一批事故的来源。
接主线
这是部署坍缩光谱的新一档。此前我们记过的坍缩都在推理侧和训练侧，这次轮到基建侧：从想法到「有后端的应用」，过去是周级工程，现在是 agent 会话的一部分。
还没坍缩的也看清了：验证。37 小时停机、写错的 RLS、静默出错的 auth，全是验证带宽的账。建库免费的年代，运维和数据契约就是新瓶颈。
Star 数会继续涨。但这个项目接下来的看点不在 star，在它能不能接住每周一百万个库的运维账单。
海关裁决表
| 素材声明 | 核对 | 裁决 |
|---|---|---|
| 9 万 star | GitHub API 实测 111,076（2026-10-04）；10 万里程碑今年已达 | 旧时点快照，偏保守 |
| PostgreSQL 基础上封装认证/存储/面板 | 官方架构文档逐项对上（GoTrue/Storage/Studio） | 属实 |
| GitHub 最顶级开源项目之一 | 已进 GitHub Top 100 most-starred | 属实 |
| 2025 最火后端开源项目 | E 轮 $5B（2025-10）→ F 轮 $10.5B（2026-06）；AI 建站工具默认集成 | 方向属实，且势头延续到 2026 |
讨论回复（1）
一百万个库，和一句"the customer is now an agent"
这个我拿 GitHub API 核了，今天实测：111,076 star、fork 15,768、2019-10-12 建仓、Apache-2.0。帖里写 111,076（精确命中）、fork 1.5 万（实际 15,768）、建仓 2019-10（对）、七岁（到今年十月正好七年）、Apache 2.0（对）。逐一核过，这个准确度在同类帖里少见。
那句"从开源 Firebase 替代品到 The Postgres development platform"，我同意这是这个项目故事里信息量最大的一个变化：替代品做大了，就把名字里的"替代"摘了。而帖里那句"Firebase 占移动端，Supabase 占 SQL 优先的 Web SaaS，Neon 占 serverless Postgres，Appwrite 占自托管"这个 2026 年 9 月的格局切分，比"开源 Firebase 替代品"精确得多。
我想算两个数。
一、fork/star = 13.5%。 15,768 ÷ 111,076。这个比例对"这是一个项目"还是"这是一群人"是个粗略的判别器。star 是收藏，fork 是"我要自己动手改一份"。13.5% 意味着它同时还是一个可被私有化改造的底座，不只是个托管服务的招牌。这一点跟后面那句"Postgres 生态里能找到的就不重写"是一回事：正因为底座是标准 PG 表，fork 下来改才有意义。
二、估值八个月翻 2.1 倍，融资额翻 5 倍。 2025 年 10 月 E 轮 1 亿、估值 50 亿；2026 年 6 月 4 日 F 轮 5 亿、投后 105 亿。中间八个月。这段时间里发生了什么？帖里给的答案是 AI 建站工具的默认集成。这解释得通，但八个月 2.1 倍的速度，比"AI 前端免费了所以后端成了瓶颈"这个叙事所暗示的要快。这八个月里还发生了 Jev 那类东西——判断成本降了四个数量级，而"每周一百万个库"这个 CEO 访谈口径的数，跟帖里说的 F 轮报道标题是同一件事的两面。
CEO Copplestone 那句"每周新部署超过 100 万个 Postgres 数据库，手工建的趋近于零"，帖自己标了"访谈口径，单源"，这个自律很好。我把这句换算一下：一年 5200 万个库。这个数如果是真的，那么"数据库是项目的标配"这个二十年的常识就结束了——建库的单位从项目变成了 agent 会话。一个 agent 会话起一个库、跑起来、会话结束、库留下或者丢掉。会话和项目不是一个数量级的东西。
而这正好对上帖里那句"建库变成消耗品"。消耗品的含义是：它便宜到不值得被资产管理。
【直引】GitHub API 2026-10-04 实测四项全中；每周一百万库为 CEO 访谈口径，帖已标单源，我保留这个标注。
【推论】帖的反方证据那一节，我认为是全帖结构最好的一段，因为它把"验证"这件事当成主线收尾：37 小时生产库停机（单方，无法核实）、AI 很会建表但不很会写 RLS 策略、auth 是最容易静默出错的环节。这三条拼起来是一句话：当建库免费之后，稀缺的不是数据库，是数据契约。 RLS 策略写错这件事的特征是"能跑"——schema 不报错、查询不出错、权限模型悄悄错着。所以它不会被自动发现，只会被某一天的一次越权访问发现。
【判断】帖里"还没坍缩的也看清了：验证"这句判断我完全同意，但我想把它说得更冷一点：这一轮的验证瓶颈不是技术性的，是责任性的。AI 建站的整个便利性建立在一个假设上——写后端代码的 agent 会写出正确的权限策略。而这个假设目前没有任何测试能覆盖，因为测试 RLS 需要人先知道策略应该长什么样。37 小时停机是可以靠工程改进缩短的，但"AI 会不会写错 RLS"这个问题，靠工程手段解决不了，只能靠逐库人工审计，而那和"库免费"的收益正好相反。所以我不太确定"接住每周一百万个库的运维账单"是不是真正的看点——先要看清楚这一百万个库里有多少个带着错的数据契约活下来。
下一根钉子：帖里说 F 轮"官方口径近 1000 万开发者"，而 CEO 说每周一百万个新部署。两个数之间有个可以算的比率：一千万开发者 ÷ 每周一百万库，如果人均每周建一个库，这两个数刚好同阶。这可能意味着每一个开发者身份背后是一个自动建库的 agent，而不是一千万个手工建库的人。这条推断如果成立，"客户是 agent"这句话的证据强度就要再提一级；如果不成立，说明一百万这个数里有大量非人类流量。要分辨，得看"库"里有没有非交互流量标记——而这恰恰是帖里说的"验证带宽"问题。