Supabase深度解析：站在Postgres与AI代理交叉口的百亿估值后端平台

Supabase 这个名字，如今的 vibe coder 们恐怕再熟悉不过了。它背后的公司成立于 2020 年，死死咬住 PostgreSQL 这个核心，把认证（Auth）、存储（Storage）、边缘函数（Edge Functions）、向量（Vector）等一系列能力打包成一站式后端，摆在开发者面前。早期它讲的故事很直接——“开源的 Firebase”，一个更简单、更易上手的 Postgres。目标也充满诱惑：让开发者能够“Build in a weekend. Scale to millions”。

Supabase 真正的底座，是过去二十年间 PostgreSQL 积累的庞大生态：官方文档、Stack Overflow 上的无数回答、GitHub 上的海量代码，这些都成了 AI 模型预训练的养料。再加上 pgvector 在向量检索领域的巨大成功，现在你问 AI 代理“该用什么数据库”，它大概率会默认推荐 Postgres。Supabase 的 BaaS 平台，则顺势提供了最开箱即用的 Postgres 体验，稳稳接住了这波分发红利。如今它已成为 Lovable、Bolt 等第三方开发工具的默认集成，也是 Codex、Claude Code 等命令行代理的首选后端推荐。

AI 编程能力的爆发是另一股巨浪。Anthropic 的 ARR 在 Opus 4.5 发布后，三个月内从 90 亿美元飙升至 300 亿级别，用两三年时间跑完了 Google Cloud 十八年的路。受益于 vibe coding 和自动化编程的崛起，Supabase 的用户增长曲线，也在 Opus 4.5 发布后开启了新一轮加速。

眼下，Supabase 即将完成由 GIC 领投的 5 亿美元 F 轮融资，估值直奔 100 亿美元。截至 2026 年第一季度，其累计用户已突破 700 万。我们预计，到 26 年底，它的 ARR 很可能攀升至数亿美元的规模。

为什么要关注 Supabase

编程代理是科技史上增速最快的新物种

1. Supabase 同时踩中了 AI 时代的两条主线： Postgres 正成为 AI 的“心智语言”，而编程则是 AI 需求的最大爆发点。Coding 是当前 AI 的核心叙事。我们的判断是：“当编程代理实现时，AGI 的 90% 也就实现了。” Postgres 的瑞士军刀属性与 pgvector 的成功，让它极适合 AI 时代的新型负载，而 Supabase 恰好是其中最流行、最易用的 Postgres 包装器，卡在了 Postgres 生态与 AI 编程趋势的完美交叉点上。

2. 产品路线图已转向服务代理。 2024 年以前，Supabase 的核心价值是让人类开发者更舒服地使用 Postgres——把 GoTrue、PostgREST 等开源组件打包，配上漂亮的仪表盘和清晰的文档，一键 setup。但从 2024 年收购 OrioleDB 开始，它开始深入改造 Postgres 本身，产品重心明显转移。我们统计了 2020 年以来 Supabase 重大更新的方向变化，能清晰地看到这一趋势。

为了达成这一目标，Supabase 通过一连串的收购，把 Postgres 领域最顶尖的人才聚拢到了一起。

我们判断，在代理时代，所谓“人类开发体验”的壁垒会随时间递减，而底层能力的壁垒却会递增。代理可以直接运维基础设施，不在意仪表盘好不好看、配置简不简单，但底层能力的强弱，依然生死攸关。

3. BaaS 处于吃掉其他基础设施的绝佳位置。 模型正在吞噬应用和垂直领域，而 Supabase 这类 BaaS，正站在消化向量搜索、状态持久化、认证等周边能力的完美起点上。凭借 Postgres 的万能属性和 Auth 等产品的高成熟度，其平台化机会非常可观。

4. 极强的分发护城河。 第一阶段，这表现为各大 vibe coding 平台的官方集成；目前，则已过渡到 AI 代理的主动推荐，以及与 Anthropic 的官方合作。AI 编程工具生成代码时选择 Supabase，并非因为商业合作，而是因为其开源社区的声量、品牌知名度、以及极高的代码示例密度都太强了。在数据库、认证、实时通信等品类中，代理对它的推荐率均稳居前三。

Momentum

Supabase 在 2024 年 4 月才正式宣布 GA，随即开启了用户和商业化的狂飙。2025 年 10 月宣布新一轮融资时，其 ARR 已突破 7000 万美元。我们预计，26 年其净新增 ARR 将大幅加速，年底有望达到数亿美元。根据 Coatue 在 26 年 3 月发布的图，过去 16 个月，Supabase 的累计用户数增长了 7 倍，已超越 700 万。

Supabase 的产品路线图

Overview

每个 Supabase 项目，本质上是一个独占的 Postgres 数据库，外加五个默认启动的服务（Auth / Storage / Realtime / Edge Functions / Vector），以及一套自动生成的 REST 和 GraphQL API。在 AWS 上这通常得拼凑五到七个服务，而在 Supabase 这里，一套 schema、一个认证上下文就全齐了。

我们可以将其产品大致分为五层：

1. Postgres 本身： 每个项目一个完整的托管 Postgres，带行级安全（RLS）、40+ 扩展、每日备份与时间点恢复（PITR）、只读副本。
2. 核心 BaaS 组件： 六大核心产品，系统自动生成 API。

3. 开发者工作流：
   • Studio Dashboard：提供包括 Table Editor、SQL Editor、AI Assistant 在内的完整可视化管理界面。
   • CLI + 声明式 Schemas + Branching：支持本地开发、迁移，并能像 Vercel 那样为每个 PR 拉起一个隔离的真实数据库环境。
   • MCP Server + agent-skills：兼容 18+ 种主流编程代理。
   • Management API + Terraform Provider：实现多项目舰队的可编程管理。
   • Logs & Analytics + Log Drains：支持将日志导出至 Datadog、Grafana 等。

4. 企业级能力： 包括 Supabase ETL、Analytics Buckets (基于 Iceberg/Parquet on S3)、Private Link (AWS VPC Lattice)、SOC 2 Type 2 / HIPAA / ISO 27001 等合规认证、Foreign Data Wrappers、Read Replicas 等。
5. 前沿探索： 押注未来。

其产品定价分为四个档次，从免费到面向超大规模应用的定制企业版。

Agent-First Bets

Supabase 产品的许多历史优势，都体现在人类开发者的体验上。但自 2025 年下半年以来，编程代理已逐渐成为决定新项目后端选型的关键角色。与人类相比，代理在生成代码时表现出三个显著差异：

• 代码产出量远超人类 1000 倍以上。
• 绝大多数产出属于一次性消耗品，真正交付到最终用户的比例很低。
• 上下文保留能力成为任务完成度的关键瓶颈，代理受限于上下文窗口，很难同时协调超过 3–4 个外部服务的 API。

这三点共同决定了一个事实：要赢得默认地位，后端产品必须同时满足三个条件——代理能针对该后端产出高质量代码、实验阶段不产生任何云成本、从原型到付费交付的升级路径能在同一供应商内闭环。针对此，Supabase 在产品上布下了三层棋子：

• agent-skills 仓库 & MCP server： 官方维护了经校验的代码模板库，已被 18+ 主流代理原生集成，代理在生成 Supabase 代码时会优先引用，从而减少幻觉和错误。
• 轻量沙盒 PGlite： 这是一个仅 3MB 的 WASM 构建版 Postgres，能在浏览器、Node.js、Bun、Deno 内亚秒级冷启动，完全兼容 Postgres 语法，但不依赖任何云资源。这让用户能以 local-first 的方式与代理快速进行原型迭代，零成本。
• BKND 和 Supabase Lite： 这是一个完全将代理视为用户的独立产品。传统上，Supabase 需要人类用户自己完成域名、环境变量等配置。Supabase 收购 BKND，并让创始人 Dennis Senn 主导 Supabase Lite，目的就是将此环节产品化：提供一个代理可直接调用的“最小可发布项目”，并内置向完整版升级的路径。虽然仍在建设中，但如果 26 年能 GA 且获得代理采用的实质牵引力，将极大增强我们对它 Agent-first 时代的信心。

Scalability Bets

Postgres 本身是个单机数据库，天生存在可伸缩性问题。根据对 12 位 Supabase 客户的专家访谈，单机 Postgres 在生产负载下的实用上限大约在：写入吞吐 1-5 万 TPS，单实例有效存储 ~10 TB，VACUUM 在 5TB 以上的表上维护成本急剧恶化。对应的客户流失拐点，大约是 20-50 万美元 ARR、5000+ 月活用户或 5-50 TB 数据量时。

为解决此问题，Supabase 有两手核心布局：

• OrioleDB： 一套替代存储引擎，旨在根治原生 Heap 存储中 VACUUM 开销大和 MVCC 导致表膨胀的顽疾。它采用 Copy-on-Write 与行级 WAL，在写密集型负载下几乎可以忽略 VACUUM 开销。
• Multigres： 由 Vitess（支撑了 YouTube 级负载的 MySQL 分片中间件）的联合创始人 Sugu Sougoumarane 主导。目标是将 Vitess 的分片模型移植到 Postgres 生态，让客户在不修改 SQL 接口、不迁移关联服务的前提下获得水平扩展能力。

这两个布局不仅关乎吸引企业客户、减少客户流失，也关乎降低服务大量一次性“沉睡项目”的云成本。整个事情带来的用户经济模型改善，从下图可见一斑：从一台顶配机器扛所有，到十台中等机器加智能路由的水平扩展，基础设施成本可以有巨幅下降。

Enterprise-Readiness

过去五年，企业 IT 拒绝 Supabase 这类 PLG 起家平台的理由集中在四点：OLAP 打通能力有限、数据库无法满足网络隔离要求、缺少企业级合规证明、以及缺少正式的企业销售与迁移服务。从 2025 年上半年到 2026 年第一季度，Supabase 的一系列产品布局正试图扭转这一点：

• OLAP 连接： 发布 Supabase ETL（流式 CDC 到 Iceberg）、Analytics Buckets (Iceberg/Parquet on S3）、Iceberg FDW 等，形成一条完整的“OLTP + OLAP on open formats”链路。
• 网络隔离： PrivateLink (AWS VPC Lattice) 已于 2026 年 1 月 GA，覆盖了 60%-70% 的隔离需求场景。
• 合规： 已取得 SOC 2 Type 2、HIPAA with BAA，ISO 27001 stage 2 接近尾声，Trust Center 已上线。
• 销售与咨询团队： 已在全球三地启动招聘，岗位职责明确包含对 Oracle 与 SQL Server 客户的迁移服务。

目前存在的企业级差距包括缺少开箱即用的 SCIM、Managed BYOC、PCI DSS 及 FedRAMP。我们判断其企业就绪度大约在 75%，缺的主要是 SCIM 和 BYOC 两项关键能力。

增长 Driver

下面两个增长引擎，解释了 Supabase 自 2025 年以来的高速增长，且其确定性在未来 6-12 个月非常高：

与初创公司一同成长

其使用量驱动的计费模型，意味着一旦客户入坑，其对 Supabase 的营收贡献将随客户自身扩张而线性甚至超线性增长。目前，有 65% 的 YC 投资公司是 Supabase 的客户。

Vibe coding

驱动来自两方面：

• 收入分成： Lovable、v0、Bolt 等平台将 Supabase 作为默认后端内置，并按用户配置的数据库向 Supabase 分成或反向采购 API quota。
• 非平台的独立 vibe coder： 决策路径已从看 Hacker News、GitHub Stars，演变为直接听从编程代理的推荐。Claude Code、Codex、Cursor 等通用代理虽与 Supabase 无商业合作，但在生成代码或问答时，倾向于主动推荐它。这让 Supabase 几乎零成本获得了海量流量。

第三方从数百个 Claude Code 会话中统计的代理推荐比例显示，Supabase 在数据库、认证、实时通信等多个类目中都位列前三。

关键挑战/Risk

竞争

Supabase 面临三维竞争：

• Postgres 生态内的云厂商与 Neon 等： 提供更纯粹的 Postgres 数据库，适合视 Supabase 平台化为供应商锁定的客户。
• Convex 等架构差异化的 BaaS 对手： 在响应式应用上契合度远高于 Supabase，是目前 vibe coder 社区中一个极具心智的替代品。
• Insforge、db9 等 Agent-first 竞争者以及 AI 发展的不确定性： 若代理自主性提升至不再依赖训练语料中的品牌惯性，Supabase 当前的分发护城河将受到结构性削弱。

单位经济模型 (UE)

尽管获客成本极低，但免费层产生的大量沉睡数据库需要预留云资源，这会限制其毛利率和单位经济模型的上限。目前虽有自动暂停机制，但更彻底的解决方案仍依赖于 Multigres、Supabase Lite 等产品的进展。

TAM 与企业客户市场

目前，Supabase 虽拥有一些大企业 logo，但仅被用于其内部创新项目，例如 Cisco、Thermo Fisher、Bloomberg 等，均明确表示不适用于关键基础设施。若仅考虑应用开发者群体扩张及 BaaS 在 AI 应用中的渗透，Supabase 所处的新兴市场体量大约在 78 亿美元级别。

这与 Oracle、Snowflake 等已完成平台化并主攻企业的数据平台 TAM 相比，差距在两到三个数量级。因此，Supabase 在企业市场的品牌接受度、可伸缩性拓展进度、以及 GTM 能力构建，对其 TAM 拓展至关重要。

团队

Paul Copplestone — CEO、联合创始人
农场背景，18 岁开始技术承包，后在对冲基金和埃森哲工作，随即连续创业。2020 年与 Ant Wilson 在 Entrepreneur First 项目匹配，共同创立 Supabase。其运营哲学强调开源是“不对称优势”，推崇无会议工程文化，主张“收购已经做成过该事的人，而非训练他人从头做”。负责资本分配、对外叙事和开源战略。

Ant Wilson — CTO、联合创始人
帝国理工软件工程硕士背景，拥有多次加速器经历。与 Paul 的分工在六年间历经三次平台级转型（YC 产品 → 开源项目 → 云 SaaS）而保持稳定。负责工程文化、Postgres-native 架构、分布式系统与存储设计。

附录

Supabase 的四笔收购解读

Supabase 的成本结构问题很直白：每个用户项目对应一个独立的托管 Postgres 实例。Free tier 用户占了大量实例但不付钱。Pro 用户每月只付 25 美元，但 Supabase 要为每个实例承担 AWS 的计算和存储费用。这意味着毛利正被基础设施成本侵蚀。它的四次收购都在从不同角度解决这个根本问题。

OrioleDB（2024.04）—— 用更少的资源做更多的事

OrioleDB 是 PostgreSQL 的替代存储引擎。Postgres 默认的 Heap 引擎有三大顽疾：表膨胀、严重依赖 VACUUM 清理、高并发下的缓存池瓶颈。OrioleDB 的方案很彻底：

• MVCC 基于 Undo Log： 原地更新，从根本上消除膨胀，告别 VACUUM。
• 索引组织表： 数据直接存在索引结构里，消除 Heap 层的额外开销。
• 消除 buffer mapping： 内存页直接链接到存储页，实现无锁读取。
• Copy-on-write checkpoints + Row-level WAL： 日志更紧凑，更易并行化。

性能提升非常直观：只读测试快 4 倍以上，读写测试快 4.5 倍以上，TPC-C benchmark 快 5.5 倍，存储空间压缩 4-5 倍。这对 Supabase 而言，直接改善了毛利率，降低了存储和运维成本，并为代理工作负载的频繁更新场景提供了可行方案。更重要的是，OrioleDB 并非开箱即用，需要对 Postgres 核心打约 20 个补丁，这意味着它是一项 Supabase 独有的能力，创造了定价权。

Multigres / Sugu Sougoumarane（2025.06）—— 突破单机限制

Multigres 是 Vitess 的 Postgres 改编版。它在 Postgres 前加一层智能代理，让多个 Postgres 实例在应用看来如同一个数据库。这直接解决了单节点写入瓶颈、垂直扩展成本非线性增长、以及企业客户天花板问题。它不仅可以解锁高 ACV 客户，还能通过更高效的多租户管理模式，改善大量小数据库的成本结构，为代理的高频写入工作负载扫清障碍。在 Postgres 生态中，提供 Postgres-native 分布式能力的公司极少，这让 Supabase 再次获得了独家定价权。

Hydra / pg_duckdb（2025.12）—— 让 Postgres 做分析

通过 pg_duckdb 扩展，一个复杂分析查询可以自动由列式引擎 DuckDB 在 Postgres 内部执行，速度提升数十到数百倍。同时推出的 Analytics Buckets 则提供了 Postgres 接口下的列式存储。这解决了混合负载下的资源竞争，避免收入流向 Snowflake，打开了 upsell 通道，并为 AI/RAG 场景打下从 OLTP 到分析到向量检索的完整数据栈基础。

BKND（2026.02）—— 服务新型用户

BKND 是一个轻量级的通用后端系统。它的引入旨在服务一种全新用户——AI 代理。代理不需要仪表盘或漂亮的 UI，需要的是：轻量、可编程、状态管理和 MCP 集成。传统的 Supabase 对此而言太“重”了。BKND Lite 旨在以极低的资源开销服务海量间歇性的 agent workload，开辟了数倍于现有市场的 TAM，并补全了 agent-native 的 MCP 生态。

客户访谈反馈分析

我们使用 8 个维度对 12 份 Supabase 客户访谈进行了情感分析，以下是可视化概览：

总体来看，其在开发者体验（DevEx）、Postgres 相关性以及认证维度上获得了受访者高度一致的正面评价，而在可伸缩性和企业级能力上，则评价分化明显，这与此前分析的挑战完全吻合。