Supabase：百亿美元估值，vibe coding 的默认后端？

海外独角兽 / Patrick · Original

海外独角兽（拾象）出品，作者 Patrick。这篇本质上是一份投研报告，结构完整：为什么关注 → 增长势能 → 产品路线图 → 增长驱动 → 风险 → 团队 → 四笔收购技术深拆。信息密度非常高，尤其是四笔收购的技术分析和 12 份客户访谈的数据。

为什么要关注 Supabase

Supabase 2020 年创立，以 Postgres 为核心数据库，叠加 Auth、Storage、Realtime、Edge Functions、Vector 等能力打包成一站式后端，早期定位”开源 Firebase”。目标是让开发者”Build in a weekend. Scale to millions”。

拾象认为 Supabase 同时踩在两条大势上：

第一条：Postgres 成为 AI agent 的”心智语言”。 过去 20 年 Postgres 的官方文档、Stack Overflow 答复、GitHub 代码都成了模型预训练数据的一部分，加上 Postgres 生态的多样性和 pgvector 的成功，目前 AI agent 在”用什么数据库”这个问题上大多数时候默认推荐 Postgres。Supabase 提供了最开箱即用的 Postgres，承接了这个分发优势。

第二条：Coding agent 爆发。 Anthropic ARR 在 Opus 4.5 发布后三个月从 $90 亿跳至 $300 亿级别。Supabase 的用户增长曲线也在 Opus 4.5 发布后完成新一轮加速。

拾象的一个关键判断：“人类开发体验的壁垒在 agent 时代是随时间递减的，而底层能力的壁垒是递增的。” Agent 可以直接管理基础设施，不在乎 Dashboard 清晰度和 setup 难度，但底层能力的强弱仍然重要。Supabase 的产品路线图已经从”给人类开发者更好的体验”切换为”给 agent 更好的 Postgres 能力”。

另外，模型正在吃掉应用和垂类，而 BaaS 处于吃掉向量搜索、状态持久化、Auth 等其他基础设施的绝佳位置——Postgres 的”瑞士军刀”属性让 Supabase 有非常好的平台化机会。

增长势能

2024 年 4 月才正式 GA，开启用户数和商业化快速增长
2025 年 10 月 ARR 突破 $7,000 万
累计用户过去 16 个月 7 倍增长，突破 700 万
接近完成 GIC 领投的 $5 亿 F 轮融资，估值 $100 亿
历史投资人包括 YC、Accel、Coatue
拾象预计 2026 年底 ARR 增长至数亿美元

产品五层架构

拾象把 Supabase 的产品分成五层：

第一层：Postgres 本身。 每个项目一个完整的托管 Postgres（15/17 版本），带 RLS（Row Level Security，行级安全策略）、40+ 扩展（pgvector、pg_graphql、pg_cron、Vault、Foreign Data Wrappers 等）、每日备份与 PITR（Point-in-Time Recovery，时间点恢复）、读副本。

第二层：6 个核心 BaaS 组件。 Auth（认证，基于 GoTrue）、Storage（文件存储）、Realtime（实时通信，基于 Phoenix Channels）、Edge Functions（边缘函数，基于 Deno）、Vector（向量搜索，基于 pgvector）、Cron（定时任务，基于 pg_cron）。系统自动生成 REST API（PostgREST）和 GraphQL API（pg_graphql），schema 改了 API 立刻跟上。

第三层：开发者工作流。 Studio Dashboard（完整可视化管理）、CLI + 声明式 Schema + Branching（给每个 PR 起一个隔离的真实数据库环境，类似 Vercel 的 preview）、MCP Server + agent-skills 仓库（18+ 主流 coding agent 原生集成）、Management API + Terraform Provider。

第四层：企业级安全与合规。 SOC 2 Type 2（已取得）、HIPAA with BAA（已取得）、ISO 27001 stage 2（接近完成）。PrivateLink 通过 AWS VPC Lattice 于 2026 年 1 月 GA。Supabase ETL + Analytics Buckets（基于 Iceberg/Parquet on S3）打通 OLAP。

第五层：前沿押注。 OrioleDB（替代存储引擎）、Multigres（分布式分片）、PGlite（3MB 的 WASM Postgres，浏览器内亚秒冷启动）、Supabase Lite（面向 agent 的轻量后端）。

定价四档：Free（2 个项目）→ Pro（$25/月起）→ Team（$599/月起）→ Enterprise（定制）。

Agent-First 产品布局

2025 下半年以来，coding agent 已成为新项目后端选型的主要决策者。Agent 跟人类开发者相比有三项差异：代码产出量高约 1000 倍以上、绝大多数产出是一次性的（disposable）、受 context window 限制难以同时协调超过 3-4 个外部服务的 API。

这三点决定了：能赢得默认地位的后端必须同时满足三个条件——agent 能很好地生成该后端的代码、探索阶段不产生云成本、从原型到付费交付的升级路径在同一供应商内闭环。

Supabase 在三层布局：

agent-skills 仓库 + MCP Server：官方校验的代码模板，被 18+ 主流 coding agent 原生集成。Agent 生成 Supabase 代码时优先引用模板，降低幻觉和错误。
PGlite：3MB 的 WASM 构建 Postgres，浏览器/Node/Bun/Deno 内亚秒级冷启动，完整兼容 Postgres 语法但不依赖云资源。让用户可以 local-first 地跟 agent 快速原型迭代，零云成本。
BKND / Supabase Lite：2025 年底收购 BKND 并引入创始人 Dennis Senn 主导 Supabase Lite——一个 agent 可直接调用的”最小可发布 Supabase 项目”，内置向完整 Supabase 升级的路径。仍在建设中。

Scalability 押注

Postgres 本身是单机数据库，天然有扩展性瓶颈。拾象引用了 12 份客户专家访谈的数据：

单机 Postgres 写入上限：1-5 万 TPS（具体看 workload 类型）
单 instance 有效存储上限：约 10TB
VACUUM 维护成本在 5TB 以上的表上显著恶化
客户开始遭遇性能问题并评估迁移的拐点：$20-50 万 ARR / 5000+ 月活 / 5-50TB 数据

迁移出 Supabase 的客户通常流向 AWS Aurora、Google AlloyDB、CockroachDB。

Supabase 的两个核心布局：

OrioleDB（2024 年 4 月收购）：Postgres 的替代存储引擎，针对原生 Heap 存储 30 年来的三个”wicked problems”——表膨胀（每次 UPDATE 创建新行，旧版本堆积）、VACUUM 依赖（清理旧版本消耗大量 CPU/IO）、Buffer pool 瓶颈。OrioleDB 用 Undo Log 替代 MVCC（原地更新，旧版本存 undo log，从根本上消除 bloat，不需要 VACUUM），采用 Index-organized tables（数据直接存在索引结构里），读性能提升 4x+，读写提升 4.5x+，TPC-C 提升 5.5x，存储压缩 4-5x。当前状态：Public Alpha，HNSW 向量索引尚未接入，GA 时间未公布。关键点：OrioleDB 需要对 Postgres 核心打约 20 个 patch，只有 Supabase 能提供，AWS RDS 和 Neon 上用不了——这是独家能力。

Multigres（2025 年 6 月聘请 Sugu Sougoumarane 主导）：Sugu 是 Vitess 的联合创始人——Vitess 是 YouTube/Google 为把 MySQL 扩展到全球级别而建的分布式中间件，目前仍支撑 YouTube 的数据库层。Multigres 的目标是把 Vitess 的分片模型移植到 Postgres 生态，在 Postgres 前面加一层智能代理，让多个 Postgres 实例对应用看来像一个数据库。架构包括 MultiGateway（路由）、MultiPooler（连接池）、MultiOrch（复制/failover/consensus）、TableGroup（跨实例分片）。当前状态：R&D 阶段，无公开 GA 时间。在 Postgres 生态中，只有 Citus（被 Microsoft 收购，现为 Azure 专属）和 Multigres 提供 Postgres 原生分布式能力。

这两个布局一个解决存储效率，一个解决分片扩展。对 agent 时代特别重要，因为 agent workload 的特征是：项目/数据库创建速率极高、冷热分布极不均匀（大多数 disposable）、爆款的突发性和爆发力极强。

OLAP 能力拓展

Hydra/pg_duckdb（2025 年 12 月收购 Hydra 团队）：让 DuckDB 列式分析引擎在 Postgres 内部运行。用户发复杂分析查询时，pg_duckdb 自动判断适合用列式引擎处理，速度提升数十到数百倍。同时推出 Analytics Buckets（基于 Iceberg + AWS S3 Tables）、Supabase ETL（Postgres WAL 到 Iceberg 的流式 CDC）、Vector Buckets（embedding 冷存储），构成”OLTP + OLAP on open formats”完整链路。

商业意义：如果分析可以直接在 Supabase 里做，用户就不需要把数据导出到 Snowflake。数据留在 Supabase = 收入留在 Supabase。一个原来只付 $25/月的 Pro 用户，开始用分析功能可能变成 $100-500/月。

增长驱动

Scale with startup：主要获客漏斗顶端是初创公司和个人开发者，计费模型使用量驱动。客户从零 ARR 启动，24-36 个月内若产品 PMF 成立，Supabase 对该客户的 ARR 贡献可从零提升至数千到 $50 万级别。65% 的 YC 公司是 Supabase 的客户。

Vibe coding 分发：两条路径。第一条是 Rev-share——Lovable、v0、Bolt、Figma Make 等平台将 Supabase 作为默认后端，按用户 provisioning 的数据库分成。第二条是非平台的 vibe coder——Claude Code、Codex、Cursor、Windsurf 等通用 coding agent 本身不与 Supabase 有商业合作，但生成代码时倾向于推荐 Supabase（因为社区影响力、品牌知名度、代码示例密度都极强）。从数百个 Claude Code session 统计的 agent 推荐比例显示，Supabase 在数据库、Auth、Realtime 等品类都位于 top 3。几乎零获客成本。

拾象还提到一个有意思的演化：开发者选择后端的决策路径从 Hacker News（2010-2015）→ GitHub stars + Twitter（2015-2020）→ 开发者大会 + swag（2020-2024）→ coding agent 自动推荐（2024 至今）。

Supabase 和 Anthropic 将合作推出 vibe coding platform 产品，会进一步加强分发。

风险与挑战

竞争三个维度： - Postgres 生态内的云厂商（Aurora DSQL、AlloyDB）和 Neon：纯数据库能力场景下 Supabase 不占优，但需要开箱即用后端的场景下 Supabase 占优。Neon 被 Databricks 收购，做了存算分离但没做 BaaS 一站式，npm 下载量增长过去 6 个月显著低于 Supabase。 - Convex：非 Postgres 的 BaaS 竞争者，对 Reactive 应用的契合度远高于 Supabase，是 vibe coder 社区中心智最强的 Supabase alternative。 - Insforge、db9 等 agent-first 竞争者。

AI 发展的不确定性：如果 agent 自主性提升到不再依赖训练语料中的语法习惯和品牌传播，而是独立选择和改造后端方案，Supabase 的分发优势将受到结构性削弱。

单位经济：免费层有大量沉睡数据库需要预留云资源，限制毛利上限。auto-pause 机制已有，但更好的方案依赖 Multigres 和 Supabase Lite 的进展。

企业客户仍在探索阶段：Cisco 只用于内部创新实验室（预算约 $10 万，跟 Firebase 共享），Thermo Fisher 只用于轻量级移动应用（明确说不适合 ERP 级系统），Bloomberg 只用于内部原型和 MVP（数据量 <100GB，花费 <$20 万，认为太新不适合关键基础设施）。Enterprise-ready 程度拾象判断约 75%，缺 SCIM（用户目录同步）和 Managed BYOC（自带云）两个关键点。

TAM 差距：BaaS + AI 应用渗透的市场约 $78 亿，跟 Oracle 和 Snowflake/Databricks 的 TAM 差 2-3 个数量级。Enterprise 市场的突破对 TAM 扩展至关重要。

团队

Paul Copplestone — CEO：新西兰南岛 Kaikoura 农场背景。18 岁开始做技术外包，在对冲基金做过平台开发，Accenture 澳洲做过项目管理。2015-2017 年在吉隆坡联合创立 ServisHero（东南亚家政服务平台），2018-2019 年创立 Nimbus for Work。2020 年通过 Entrepreneur First 新加坡跟 Ant Wilson 匹配，共同创立 Supabase，同年进入 YC S20。运营哲学：开源作为”不对称优势”，“no-meetings”工程文化（全公司每周一次例会），全球远程团队，主动招聘前创始人，“收购已经做成过该事情的人，而非训练他人从头做”。

Ant Wilson — CTO：Imperial College London 软件工程硕士。先后在多家公司任工程岗位，经 EF 新加坡与 Techstars 伦敦两个加速器。跟 Paul 在 EF 配对创立 Supabase。负责工程文化、Postgres-native 架构、分布式系统。Paul 评价他非常善于跟投资人沟通。

拧巴的地方

分发优势的脆弱性。Supabase 目前最大的增长引擎是”agent 默认推荐”，但这个优势建立在训练数据偏好上，不是商业协议。如果下一代模型的训练数据分布变了，或者 agent 变得更自主不再依赖训练惯性，这个分发可能一夜之间消失。拾象自己也提到了这个风险，但没有深入讨论。
$100 亿估值 vs $7,000 万 ARR。这是 140 倍以上的 PS 倍数。即使 2026 年底做到”数亿美元”（假设 $3 亿），PS 仍然在 33 倍左右。这个估值隐含的假设是 Supabase 能从 BaaS 成功平台化进入 Enterprise 市场，但目前 Enterprise 客户全部停在”探索/sandbox”阶段，没有一个进入关键系统。
OrioleDB 和 Multigres 都还在早期。OrioleDB 是 Public Alpha，HNSW 向量索引都没接入；Multigres 在 R&D 阶段。这两个是解决 scalability 瓶颈的核心押注，但都没有 GA 时间表。如果 2026-2027 年这两个产品不能交付，高增长客户到了 $20-50 万 ARR 拐点就会迁走。
“开源 Firebase” vs “Postgres 改造者”的身份转换。文章描述了一个有趣的战略转向：从一个打包开源组件的集成商（GoTrue + PostgREST + Phoenix Channels），变成一个改造 Postgres 内核的基础设施公司（OrioleDB + Multigres）。这两种公司需要的能力完全不同——前者需要产品品味和开发者社区运营，后者需要数据库内核工程。通过收购来获得后者的能力是聪明的（“收购已经做成过的人”），但整合风险不小。