企业官网建设流程全解析

百亿美元估值刷屏：GIC、CapitalG 联手押注，Supabase 凭什么让资本追着投

【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase

当整个开源圈还在讨论 "AI Agent 该用什么后端" 时，答案似乎已经自己跳了出来。2026 年秋，多家媒体密集报道：开源 BaaS 平台 Supabase 完成新一轮融资，由新加坡主权基金 GIC 领投，Alphabet 旗下独立成长基金 CapitalG、以及知名风投 Iron 参投，公司估值一举突破百亿美元；几乎同一时间，它还宣布收购边缘数据库初创公司 Turso。一边是 GitHub 上超过 11 万 stars 的顶级开源项目，一边是主权基金与巨头系资本联手押注的百亿估值，这条增长曲线本身就足够反常——毕竟在融资寒冬里，"开源 + 免费"的故事一向最难讲。

这篇文章不打算复述融资新闻，而是回到仓库本身，用源码回答三个问题：Supabase 凭什么值百亿？它做了什么让 Firebase 都做不到的事？"开源免费、云上收费"这套叙事，到底靠什么在支撑？

从 "Firebase 替代品" 到 "Postgres 开发平台"：一次精准的自我重定位

打开仓库根目录的 README.md，第一行定位就写得很清楚：

Supabase is the Postgres development platform. We're building the features of Firebase using enterprise-grade open source tools.

"用企业级开源工具构建 Firebase 的功能"——这是 Supabase 从 2020 年诞生起就坚持的路线。但真正让它跑赢同赛道选手的，是它在 2023 年前后完成的叙事升级：不再只是 "Firebase 的开源替代品"，而是 "Postgres 开发平台"。

这个重定位的微妙之处在于：它把故事的锚点从 "竞争" 换成了 "兼容"。Firebase 的痛点众所周知——数据模型被锁定在 NoSQL 里，业务逻辑无法用 SQL 表达，迁移等于重写。而 Postgres 有三十年的可靠性口碑、最成熟的生态和最庞大的 DBA 人才池。Supabase 没有另起炉灶发明一个数据库，而是把所有 Firebase 能力——实时订阅、认证、存储、边缘函数——全部架在 Postgres 之上，让开发者既拥有 BaaS 的零后端体验，又保留 SQL 的全部能力。

仓库里的架构图直观呈现了这套设计：

一条 Envoy 网关挂载七个入口：/auth（GoTrue 认证）、/rest（PostgREST 自动生成 REST API）、/realtime（Elixir 写的实时服务）、/storage（基于 S3 的对象存储）、/pg（pg-meta 数据库管理）、/functions（边缘函数）、/graphql（pg_graphql 扩展）——全部收敛到底层同一个 PostgreSQL。注意这七个组件的许可证：PostgREST、GoTrue、pg_graphql、postgres-meta 全部是 MIT 或 Apache 2.0 系开源协议，而且其中相当一部分是 Supabase 自己写出来再开源的。这就是 README 里那句话的实践版：

If the tools and communities exist, with an MIT, Apache 2, or equivalent open license, we will use and support that tool. If the tool doesn't exist, we build and open source it ourselves.

"能用的用，没有的自己造"——这个策略让 Supabase 的每一层能力都能被社区审计、被自托管、被复用，也让它天然承接了 Postgres 三十年积累的开发者信任。信任这个东西，在基础设施软件里是最难买的。

融资逻辑的底层支撑：一份能算得清账的定价体系

资本看项目，第一件事是看单位经济模型。GIC 这类主权基金尤其如此。Supabase 打动它们的，正是那份写在 packages/shared-data/plans.ts 里的、高度工程化的定价体系。

这个文件把套餐抽象成PricingInformation接口，四个档位：Free、Pro（$25/月起）、Team（$599/月起）、Enterprise（Custom）。值得注意的不是价格本身，而是计费维度——它以资源消耗而非人头为单位拆解：

• Free 档：无限 API 请求、5 万月活用户、500 MB 数据库、5 GB 出口流量——足够个人项目从零跑起来；
• Pro 档：10 万月活用户（超出后每 MAU 收 $0.00325）、8 GB 磁盘（超出每 GB $0.125）、250 GB 出口（超出每 GB $0.09）；
• Team 档：SOC2 / ISO 27001 合规、SSO、14 天备份、28 天日志留存，面向有合规需求的中型企业；
• Enterprise 档：Uptime SLA、AWS PrivateLink、24×7 专属支持。

这套结构背后是一条标准的 "免费获客 — 用量变现 — 合规溢价" 漏斗。而它真正的护城河在 packages/shared-data/regions.ts 里：Supabase 的服务覆盖美西、美东、欧洲五个区域、新加坡、东京、首尔、孟买、悉尼、圣保罗等 15+ 个 AWS 区域。数据库是最讲究数据主权的软件品类，一套全球节点 + 多云部署的能力，意味着它可以直接卖给跨国企业和强合规行业——这正是 Enterprise 档 "Custom" 定价能支撑高客单价的底气。

更有意思的是，这套商业模型和开源代码是同一份资产。docker/docker-compose.yml 提供了完整的自托管编排：Studio、Envoy 网关、pg-meta、Postgres、Realtime、Storage 一应俱全。用户完全可以自己拉镜像跑一套私有云，Supabase 不阻止你——因为它的商业化押注从来不是 license 费用，而是托管服务的规模效应、全球节点的运维成本和 SLA 承诺。开源换信任，托管换收入，这是 "不卖 license、卖云服务" 的核心闭环。

安全模型才是产品本体：一段迁移文件看透 RLS

如果把 Supabase 的商业故事拆到最底层，真正让资本放心的是它的安全架构——更准确地说，是它把安全做进了数据库权限体系本身，而不是做在外层 API 上。

仓库里官方 Todo 示例 examples/todo-list/nextjs-todo-list/supabase/migrations/20230712094349_init.sql 是理解这套模型最好的教材。一张todos表，四条 policy，几十行 SQL 就把 "只能操作自己的数据" 这件事写进了数据库：

alter table todos enable row level security; create policy "Individuals can create todos." on todos for insert with check (auth.uid() = user_id); create policy "Individuals can view their own todos." on todos for select using (auth.uid() = user_id); create policy "Individuals can update their own todos." on todos for update using (auth.uid() = user_id); create policy "Individuals can delete their own todos." on todos for delete using (auth.uid() = user_id);

auth.uid()是 Postgres 内置的 JWT 身份解析函数。这意味着什么？权限校验发生在数据库引擎内部，任何绕过 API 网关的直连查询（连接串泄露、客户端直接走 Postgres 协议）都逃不过同一套 RLS 策略。对开发者来说，这是"前端直连数据库"模式的信任基础；对企业安全团队来说，这是可审计、可测试、不依赖应用层代码的安全边界。安全隐患是数据库公司最大的声誉风险，而把安全下沉到数据库内核，正是 Supabase 敢对百万级个人开发者开放 anon key 的底气。

押注 AI 应用时代：混合搜索与"每个 Agent 一个数据库"

资本愿意给出百亿估值，看的从来不是存量市场，而是未来三到五年的增量。Supabase 讲给投资者的增量故事，是 AI 应用。

仓库里 supabase/migrations/20250714120000_hybrid_search.sql 是这条叙事的技术注脚——一个用websearch_to_tsquery全文检索与match_embedding向量检索做 RRF（倒数排名融合）的混合搜索函数，向量维度vector(1536)直接对接 OpenAI 类 embedding 模型：

create or replace function search_content_hybrid( query_text text, query_embedding vector(1536), ... ) returns table (id bigint, page_title text, type text, href text, ...)

全文检索负责关键词精准命中，向量检索负责语义相似召回，RRF 融合两边排名——这正是 RAG 应用、文档问答、语义搜索的标准后端配方，而且全部跑在 PostgreSQL 内核里，不需要额外引入向量数据库组件。对 AI 创业者来说，这意味着 "数据库 + 向量检索 + 认证 + 存储" 一个 Supabase 全包了。

更激进的信号是 Turso 收购。Turso 是 SQLite 生态的分布式边缘数据库，主打 "靠近用户运行、每个租户独立数据库"。把两者放在一起看，Supabase 的野心已经很直白：在 AI Agent 时代，每个 Agent、每个租户、甚至每次对话都可能需要一个独立的、就近部署的小数据库——"百万级独立数据库"不再是口号，而是可预期的工程现实。收购 Turso 等于提前补上了边缘数据库这一块拼图。

所以回看这一轮融资名单，逻辑是自洽的：GIC 看重的是基础设施级现金流与全球数据主权合规赛道，CapitalG 看重的是 Google 生态里"开发者基础设施"的稀缺标的，Iron 看重的则是 AI 应用爆发带来的增量。三个视角叠加在同一个标的——一个有 11 万 stars 的社区信任、一套算得清账的云商业模式、一条通往 AI 应用时代的增长曲线的开源公司——百亿估值便不再令人意外。

结语：开源商业化的新范式样本

Supabase 的故事之所以值得反复拆解，是因为它给 "开源公司怎么赚钱" 提供了一个不同于传统 dual-license 的范式样本：代码全量开源、协议宽松（Apache-2.0）、允许自托管，商业价值完全沉淀在托管服务的规模效应、全球节点的运维工程与合规能力上。它证明了在开发者基础设施这个赛道，信任、开放与商业化可以不是零和博弈——社区每多一个 stars，云上就多一个潜在付费用户；代码每多一次被自托管审计，企业客户就多一分部署信心。

对创业者而言，Supabase 给出了一个可以抄的作业：选一个足够底层的开源组件（Postgres），把开发者体验做到极致，再把安全与合规做成产品本身，最后用 AI 时代的需求讲出第二增长曲线。对资本而言，它则验证了一个判断：在生成式 AI 把所有应用重做一遍的窗口期，谁掌握开发者信任的底座，谁就掌握下一代应用的入口。

【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase