Supabase 是一个简直通盘 vibe coder 齐熟悉的居品。

它背后的公司创立于 2020 年，以 Postgres 为核心数据库，相通 auth、storage、edge functions、vector 等才略打包成一站式后端提供给用户。其早期价值主张围绕“open-source Firebase”与“更随便易用和一站式的 Postgres”构建，方针是闪开导者“Build in a weekend. Scale to millions”。

Supabase 的发展底座是 PostgreSQL。往时 20 年 Postgres 的官方文档、Stack Overflow 回应、GitHub 数据齐成为了模子预本质数据的一部分，加上 Postgres 生态的各样性以及 pgvector 的告捷，面前 AI agent 在“用什么数据库”这一问题上大多数时候默许推选和遴荐 Postgres。Supabase 的 BaaS 平台提供了最开箱即用的 Postgres，邻接了这一分发上风，面前还是成为 Lovable、Bolt 品级三方 harness 的默许集成以及 Codex、Claude Code 等 CLI agent 的 top 后端推选。

Supabase 背后的另一个 wave 是 AI coding 才略的普及。Anthropic ARR 在 Opus 4.5 发布后三个月从 90 亿好意思元跳至 300 亿好意思元级别，run rate 两三年走完 Google Cloud 十八年的路。受益于 vibe coding 和 agentic engineering 的崛起，Supabase 的用户增长弧线也在 Opus 4.5 发布后完成新的加快。

面前 Supabase 接近完成 GIC 领投的 5 亿好意思元 F 轮融资，估值 100 亿好意思元。公司历史上要紧的财务投资东谈主还包括 YC、Accel、Coatue 等。舍弃 2026 年 Q1，Supabase 累计用户随性 700 万。咱们展望 Supabase ARR 在 26 年末不错达到数亿好意思元。

01.

为什么要蔼然 Supabase

Coding Agent 是科技史上增速最快的新物种

1. Supabase 同期在两条 AI 期间的大势上，即 Postgres 作为 AI 的心智话语，以及 coding 作为 AI 需求的最大爆发点。

Coding 是 AI 面前最大的 wave 和完全的干线，coding 才略大幅普及的 Opus 4.5 还是让 AI 从 chat 跨入 agent 期间。咱们的判断是“coding agent 杀青了，AGI 的 90% 就杀青了”。

而 Postgres 还是成为 agent 的后端心智话语，最顺应其交融和操作。收货于其瑞士军刀属性和 pgvector 的强劲告捷，Postgres 相配顺应 AI 期间的新式 workload。Supabase 告捷打造了最流行和易用的 Postgres wrapper，位置在 Postgres 生态和 AI coding 趋势的交叉点上。

2. Supabase 的居品途径图已从“给东谈主类开导者更好的体验”切换为“给 agent 更好的 Postgres capability”。

在 2024 年以前，Supabase 的主要价值是让东谈主类更随便肤浅地用 Postgres，将 GoTrue（Auth）、PostgREST（API）、Phoenix Channels（Realtime）等已有开源组件打包成一站式体验，Dashboard 悦目，文档明晰，能闪开导者一键 setup。

跟着 2024 年收购 OrioleDB，Supabase 初始成为 Postgres 的更正者，其居品途径图聚焦点明显改变。咱们统计了 20 年以来 Supabase 要紧居品更新的标的分化：

Supabase 还通过连气儿收购把 Postgres 最顶尖的东谈主才聚拢到一家公司：

咱们判断，东谈主类开导体验的壁垒在 agent 期间是随时间递减的，而底层 capability 的壁垒是递加的。Agent 不错直禁受理 infra 自己，并不着重 dashboard 明晰度和 setup 难度，但 capability 的强弱仍将要紧。

3. 模子正在吃掉诓骗和垂类，BaaS 则处于吃掉向量搜索、景象握久化、auth 等其他 Infra 的绝佳位置上。

Supabase 处于 Infra 的核心位置，相通上 Postgres 的瑞士军刀属性以及 Supabase 在 Auth 等居品拓展上的高熟悉度，有相配好的平台化契机。

4. Supabase 有极强的 distribution moat，第一阶段体现为 vibe coding 平台的官方集成，面前还是过渡到 agent 的主动推选以及与 Anthropic 的官方互助。

Supabase 是 Bolt、Figma、Lovable 等平台的默许后端，构建了官方集成，成为 Lovable Cloud 等居品的白标业绩商。

同期 AI coding 器用生成代码时遴荐 Supabase 不是因为有商务互助，而是 Supabase 的社区影响力、品牌驰名度、代码示例密度齐极强。Supabase 在数据库、auth、real time 等品类的 agent 推选率齐名列 top 3。Supabase 和 Anthropic 将互助推出 vibe coding platform 居品，会进一步加强这个 distribution moat。

02.

Momentum

Supabase 在 2024 年 4 月才认真告示 GA，开启了用户数和交易化的快速增长。在 2025 年 10 月告示新一轮融资时，Supabase 的 ARR 还是随性 7000 万好意思元。咱们展望其 Net New ARR 在 26 年将大幅加快，年底 ARR 将增长至数亿好意思元。

凭据 Coatue 在 26 年 3 月发布的这张图片，Supabase 的累计用户数往时 16 个月 7x，还是超过 700 万：

03.

Supabase 的居品路败露

Overview

每个 Supabase 容颜齐终点于一个独占 Postgres 数据库及 5 个同容颜默许开好的业绩（Auth / Storage / Realtime / Edge Functions / Vector）+ 自动生成的 REST & GraphQL API。这平庸需要在 AWS 上拼 5–7 个业绩才气作念到，但在 Supabase 这里是一个 schema 和一套 auth 险峻文里全部开好的默许。

在大体上，咱们不错把 Supabase 的居品分红 5 层来看：

1. Postgres 自己。每个容颜一个完好的托管 Postgres（15/17），带 RLS、40+ 扩展（pgvector、pg_graphql、pg_cron、Vault、Foreign Data Wrappers 等）、daily backup 与 PITR、read replicas。

2. 6 个核心的 BaaS 组件居品，同期系统自动生成 REST API（PostgREST）和 GraphQL API（pg_graphql），schema 改了 API 不错坐窝跟上：

3. 开导者 workflow：

•Studio Dashboard：完好可视化管理（Table Editor / SQL Editor / Auth Users / Storage Buckets / Logs / AI Assistant）

驾御滑动稽查完好图文

•CLI + Declarative Schemas + Branching：腹地 dev → migrations → 给每个 PR 起一个隔断的确数据库环境（Vercel 式）

•MCP Server + supabase/agent-skills：18+ agent 兼容

•Management API + Terraform Provider：多容颜 fleet 可编程管理

•Logs & Analytics + Log Drains：Datadog / Grafana / Sentry / S3 导出

4. 企业级安全、合规以及独占才略：

•Supabase ETL + Analytics Buckets (Iceberg/Parquet on S3) + S3 Tables

•Private Link（AWS VPC Lattice， 2026 岁首 GA）

•合规：SOC 2 Type 2 / HIPAA （with BAA） / ISO 27001 stage 2 尾声

•Foreign Data Wrappers（查外部数据源像 Postgres 表）

•Read Replicas + Dedicated Poolers + PITR

5. 前沿 bet：

其居品订价为如下四档：

Agent-First Bets

Supabase 居品的好多历史优点主要体面前东谈主类开导者的体验上。2025 H2 以来，coding agent 已成为新容颜后端选型的主要决策者之一。与东谈主类开导者比较，agent 在生成代码时阐扬出三项互异：

•代码产出量较东谈主类高约 1000x 以上

•绝大多数产出适当 disposable 的观念，真确寄托至最终用户的比例低

•Context retention 成为任务完成度的要紧制约，agent 才略受限于 context window，难以同期和谐向上 3–4 个外部业绩的 API 气象

以上三点共同决定：大约在这些 workload 下赢得默许地位的后端居品，必须同期中意三项条目：agent 能很好地针对该后端的代码、探索实验阶段不产生云成本、从原型到付费寄托的升级旅途能在归并供应商内闭环。

Supabase 在居品层面有 3 层的布局：

• supabase/agent-skills 仓库 & MCP server：skills 仓库采集了官方校验过的 Supabase 代码 template，面前还是被 18+ 主流 coding agent 原生集成，让 agent 在生成 Supabase 代码时优先援用其 template，镌汰幻觉和失误。

• 轻量沙盒 PGlite：PGlite 是一个 3MB 的 WASM 构建 Postgres，可在浏览器、Node、Bun、Deno 内亚秒级冷启动运行，完好兼容 Postgres 语法但不依赖任何云资源。让用户不错 local-first 地快速地跟 agent 沿途进行原型迭代，无需挥霍任何的云资源。

• BKND 和 Supabase Lite：完全面向 agent 作为用户打造的安祥居品。传统上 Supabase 需要东谈主类用户我方完成域名、环境变量、auth 成就等编排。Supabase 于 2025 年底告示收购 BKND 并引入其创举东谈主 Dennis Senn 主导 Supabase Lite，方针是将该编排设施居品化：一个 agent 可径直调用的“最小可发布 Supabase 容颜”，同期内置一条向完好 Supabase 容颜升级的旅途。这条居品线仍在设立中。面前 Supabase 对 Lite 的核心构思包括：

1) 针对沙盒环境的 trimmed-down experience

2) 面向 agentic workflow 的数据库架构

3) 更小、更低廉、更随便的数据库

面前看 Supabase Lite 还在探索阶段，要是 26 年能 GA 而且咱们不雅察到 agent adoption 的 traction，不错大幅增强咱们对 Supabase 在 agent-first 期间的信心。

Scalability Bets

Postgres 自己是一个单机数据库，在不进行存算分离等架构大改的基础上，自然有 scalability 的问题。凭据 12 份 Supabase 客户的行家访谈，对单机 Postgres 在交易级分娩负载下的实用上限为：写入隐隐 1-5 万 TPS（具体看 workload 类型）、单 instance 有用存储 ～10 TB 量级、VACUUM 爱戴成本在 5 TB 以上的表上显赫恶化。对应的交易拐点（客户初始遭受性能问题而评估移动的时间点）约为 20-50 万好意思元 ARR / 5000+ 月活用户 / 5–50 TB 数据量。

平庸来说，因为 scalability 问题而移动出 Supabase 的客户会流向云厂商等贬责决策，主流的选项是 AWS Aurora、Google AlloyDB、CockroachDB。这种移动自己也耗时耗力，需要对 auth、storage、realtime 等联系业绩作念全部的重建，但为了更好的性能、容灾等才略，客户频频不得不移动。

面前针对 scalability 的问题，Supabase 有两个核心的居品布局：

•OrioleDB。Supabase 于 2024 年收购 OrioleDB 容颜并将其创举东谈主 Alexander Korotkov 纳入核心团队。OrioleDB 是 Postgres 的一套替代存储引擎，针对原生 Heap 存储永恒未能贬责的两个问题，VACUUM 爱戴支出与 MVCC 导致的表蔓延。其期间杀青接纳 Copy-on-Write 与行级 WAL，在写密集负载下可将 VACUUM 支出压缩至可忽略区间。现时景象为 Supabase 云平台 Public Alpha，HNSW 向量索引尚未接入，GA 时间表未公开。

•Multigres。Supabase 于 2025 年礼聘 Sugu Sougoumarane 主导 Multigres 容颜。Sugu 为 Vitess（MySQL 水瓜分片中间件，在 YouTube、Slack、Square 等公司承载 exabyte 级负载）的融合创建者。Multigres 的方针是将 Vitess 的分片模子移植至 Postgres 生态，使客户在不切换 SQL 接口、不移动 Auth / Storage 等联系业绩的前提下赢得水平扩展才略。现时景象为 R&D 阶段，无公开 GA 时间表。

这两个布局一个专注在存储、一个专注在分片更正 Postgres。对 Supabase 在客户鸿沟的两头齐故真谛真谛，一方面是招引企业客户以及减少 graduation effect，另一方面是镌汰业绩 vibe coder 的千里睡容颜的云成本。同期，agent 期间后端的 workload 会有几个大的变化：

•容颜/数据库的创建速率极高

•这些容颜的冷热散播季度不均，大多数 disposable

•爆款的突发性和爆发力极强

Multigres 和 OrioleDB 后续发展会决定 Supabase 在冷容颜的成本约束和爆发容颜/企业级 workload 上的弹性邻接才略（下图为加机器扩容这一个变化带来的 UE 改善）。

Enterprise-Readiness

凭据行家访谈，往时 5 年，企业 IT 采购对 Supabase 这类 PLG/self-serve 起家的后端平台的隔断意义集结在四类：

•跟企业现存 OLAP 的数据买通才略有限

•无法中意数据库不得线路于公网的汇集隔断要求

•空泛一些企业级合规阐述

•比较 Crunchy Data 等 Postgres 业绩商，空泛认确实 enterprise sales 与移动业绩

Supabase 从 25H1 到 26Q1 有一系列改善这些情况的居品布局：

•OLAP 结合：有一系列要紧发布，包括 Supabase ETL（Postgres WAL 到 Iceberg 的流式 CDC）、Analytics Buckets（基于 Iceberg 与 Parquet on S3 的托管对象存储）、Iceberg Foreign Data Wrapper、以及与 AWS S3 Tables 的互助，系数组成“OLTP + OLAP on open formats”的完好链路

•汇集隔断：PrivateLink 通过 AWS VPC Lattice 于 2026 年 1 月 GA，躲闪企业采购清单中“数据库不得线路于公网”要求的 60%–70% 场景。剩余场景波及 GCP 与 Azure 客户的同等私网结合才略，仍在设立中

•合规：SOC 2 Type 2（已取得）、HIPAA with BAA（已取得）、ISO 27001 stage 2（接近尾声）。Trust Center 已上线。躲闪大部分交易 B2B 与医疗健康场景的合规准入

•Sales 与 advisory 团队：Strategic CSA（Customer Success Architect）团队在 AMER、EMEA、APAC 三地的招聘已启动，含 Team Lead 岗亭；岗亭 scope 明确包含对 Oracle 与 SQL Server 客户的移动业绩

面前还存在的 enterprise gap 包括：

•SCIM：Supabase 不提供开箱即用的 SCIM，客户需要使用 API、SQL、Webhooks 自行构建

•Managed BYOC：面前莫得这项才略，很难卖给高监管行业和政府

•PCI DSS：面前莫得但无用须，主要影响需要在数据库内处理信用卡数据的收付款场景

•FedRAMP：面前莫得，但拓展联邦政府及国防客户需要领有

咱们判断 Supabase 的 Enterprise-ready 程度在 75% 驾御，空泛 SCIM 和 BYOC 两个关节点，但基本的辅助齐还是领有或者在设立，需要要点随性的照旧 scalability。

04.

增长 Driver

底下两个 growth driver 是 Supabase 在 2025 年于今能赢得高速增长的主要原因，而且面前看赓续延续 6-12 个月的细目性相配高：

Scale with startup

Supabase 的主要获客漏斗尖端为初创公司与个东谈主开导者，计费模子为使用量驱动（database size、compute hours、active users、egress 等）。这意味着一朝客户投入 Supabase 生态，其对 Supabase 的营收孝顺将随该客户自身鸿沟扩张而线性以致超线性增长。客户从零 ARR 启动容颜，24–36 个月内若居品 PMF 成立，Supabase 对该单客户的 ARR 孝顺可从零普及至数千到 50 万好意思元级别。面前有 65% 的 YC 公司是 Supabase 的客户。

Vibe coding

Vibe coding 关于 Supabase 的增长驱动有两方面：

•Rev-share：Lovable、v0、Bolt、Figma Make 等平台将 Supabase 作为默许 backend 内置，按用户 provisioning 的 database 向 Supabase 分红或反向采购 API quota。Supabase 让渡了一部分收益，但换来了更多的流量

•非平台的 vibe coder：

1) 开导者遴荐后端的决策旅途经历是：Hacker News 与期间博客（2010–2015）→ GitHub stars 与 Twitter（2015–2020）→ developer conferences 与 swag（2020–2024）→ coding agent 自动推选（2024 于今）

2) Claude Code、Codex、Cursor、Windsurf 等通用 coding agent 自己不与 Supabase 有交易互助，但其生成代码或跟用户 Q&A 时倾向于推选 Supabase

3) 这让 Supabase 简直零获客成腹地赢得了大批流量

下图为第三方从数百个 Claude Code session 种统计的 agent 推选比例，Supabase 在多个类目齐位于 top3：

驾御滑动稽查完好图文

05.

关节挑战/Risk

竞争

咱们判断 Supabase 面前有 3 个维度的竞争者：

•Postgres 生态内的云厂商和 Neon 等竞品，它们提供更义结金兰的 Postgres 数据库，顺应那些将 Supabase 平台化才略视作 vendor lock-in 的客户

•Convex 等架构互异化的 BaaS 竞争敌手

•Insforge、db9 等 agent-first 竞争者以及 AI 赓续发展的不细目性

云厂商原生 Postgres：Aurora DSQL、AlloyDB 等

AWS 与 Google 具备将 Postgres 兼容层相通于其散播式存储基础设施之上的工程才略，OD体育(ODSports)并可在单项 benchmark（隐隐、蔓延、可用区容错）上向上 Supabase。已有 AWS commit 预算且仅需纯数据库才略的企业客户，默许遴荐 Aurora 或 AlloyDB，Supabase 在此场景中完全不占优。但在诓骗需要开箱即用后端的场景中，Supabase 占优。

Serverless Postgres：Neon 等

Neon 专注于存算分离、即时辰支等期间标的，引颈了 OrioleDV 以外的另一条途径。在海量的、短命命的一丝据库 workload 上，Neon 的架构更顺应，它也的确有 Replit 作为客户。Databricks 于 2025 年完成对 Neon 的收购。

在 Neon 之上构建完好诓骗需客户从新拼接 Auth、Storage、Functions、Realtime 四个安祥供应商。这导致 Neon 的 npm 下载量增长在往时 6 个月显赫低于 Supabase 和 Convex。但仅需纯数据库才略的企业客户或者资深的开导者会遴荐 Neon 然后自行拼接其他业绩。

NoSQL/Non-Postgres 的竞争敌手：Convex

咱们之前贵重先容过 Convex 的期间特色和潜在 TAM。关于 Reactive 的诓骗，Convex 的契合程度远高于 Supabase，它亦然面前 vibe coder 社区中心智最强的 Supabase alternative。

AI 快速发展的不细目性

若 agent 的自主性普及至不再依赖本质语料中的语法习气、品牌传播等，而是更自主独迅速遴荐和更正现存后端决策，面前 Supabase 的 distribution moat 将受到结构性温顺。

UE

Supabase 诚然获客成本很低，但它的免费层居品有大批的千里睡数据库需要预留云资源，会约束其毛利和 UE 的上限。面前 Supabase 有 auto-pause 机制，但更用户友好的决策依赖于 Multigres、Supabase Lite 等居品押注的进展，毛利率和 UE 的趋势是后续和公司交流的要点。

TAM & 企业客户阛阓

面前 Supabase 领有一些大型企业 logo，但仍然仅被用于其更动性的探索容颜。以下为客户访谈中的一些案例：

•Cisco（VP Data Analytics & AI）：仅限里面更动实验室 sandbox 使用，预算约 10 万好意思元且与 Firebase 分享，觉得企业级还不熟悉

•Thermo Fisher（Director IT Operations）：仅用于轻量级出动诓骗，约 15 个 app，明确示意不顺应 ERP 级别的关节系统

•Bloomberg（Head of CTO Compute Architecture）：仅用于里面原型和 MVP，数据量

若仅酌量诓骗开导者这一群体的扩张和 BaaS 在 AI 诓骗中的浸透，Supabase 所处的这一新兴阛阓的体量在 78 亿好意思元级别：

这一 TAM 和 Oracle 以及 Snowflake、Databricks 等还是完成平台化且主攻 Enterprise 的新兴数据平台公司的 TAM 对比，差距在 2-3 个数目级。因此 Supabase 在 Enterprise 阛阓的品牌接受度、scalability 拓展进程、GTM 才略构建关于其 TAM Expansion 齐至关要紧。

06.

团队

Paul Copplestone — CEO、融合创举东谈主（2020 年于今）

•经验：新西兰南岛 Kaikoura 农场布景。18 岁高中毕业后初始 tech contracting，本科就读于 University of Canterbury（2007 年赢得 Bachelor's degree），期间握续兼职开导。毕业后赴澳洲，首份全员职责在一家对冲基金作念平台开导，随后加入 Accenture 澳洲（医疗与群众部门容颜寄托）作念容颜管理。相识到这条旅途不是我方思要的之后转入创业：2015–2017 年在 Kuala Lumpur 担任 ServisHero（东南亚最大的家政业绩阛阓之一）CTO／融合创举东谈主；2018–2019 年创立 Nimbus for Work（办公管理平台）。2020 年 1 月通过 Entrepreneur First 新加坡容颜与 Ant Wilson 匹配，共同创立 Supabase，同庚投入 YC S20。

•运营形而上学：开源作为“分歧称上风”（asymmetric advantage）；“no-meetings”工程文化，全公司每周一次例会；全球良友团队，主动招聘前 founder；“playing startup vs. strategy”，分别“把创业四肢演出”和“把创业作为政策器用”；“收购还是作念成过该事情的东谈主，而非本质他东谈主从新作念”。

•职能单干：成天职派、招聘形而上学、对外叙事、开源政策。通盘首要居品与组织决策经其本东谈主输出。

Ant Wilson — CTO、融合创举东谈主（2020 年于今）

•经验：Imperial College London 软件工程硕士。先后在 Airsorted、Stylindex、Crypto Squad 等公司任工程岗亭，经 Entrepreneur First 新加坡与 Techstars 伦敦两个加快器容颜。与 Paul 在 EF 新加坡的 matching 阶段配对共同创立 Supabase

•职能单干：工程文化、Postgres-native 架构、散播式系统、存储与 HA 贪图。与 Paul 的单干在六年三次平台级转型（YC 居品 → 开源容颜 → 云 SaaS）经过中保握自如。Paul 称其相配善于和投资东谈主调换

07.

附录

Supabase 的四笔收购解读

Supabase 现时的成本结构问题很直白：每个用户容颜对应一个安祥的 managed Postgres 实例。Free tier 用户占了大批实例但不付钱。Pro 用户每月只付 25 好意思元，但 Supabase 要为每个实例付 AWS 的 compute + storage 用度。这意味着其毛利在被基础设施成本侵蚀。

它的四次收购齐在从不同角度贬责这个根底问题。

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

OrioleDB 是一个 PostgreSQL 的替代存储引擎。Postgres 默许的存储引擎叫 Heap，从 1986 年用到面前。OrioleDB 通过 Postgres 12 引入的 Table Access Method（TAM）接口，提供了一个全新的存储层。你不错在归并个数据库里，某些表用 Heap，某些表用 OrioleDB，就像 MySQL 的 InnoDB 和 MyISAM 不错共存一样。

Postgres Heap 存储引擎有三个人所共知的“wicked problems”

• 问题 1：Table bloat（表蔓延）。 Postgres 的 MVCC 杀青样式是：每次 UPDATE 一瞥，不是修改正本的行，而是创建一条新行。要是一瞥数据被 UPDATE 了 10，000 次，内外就有 10，000 行旧版块。这些旧版块即是 bloat。Bloat 占用磁盘空间、拖慢查询、加多 I/O。

• 问题 2：VACUUM 依赖。 为了清算 bloat，Postgres 需要按期运行 VACUUM。VACUUM 自己挥霍 CPU 和 I/O，要是成就不妥会导致性能下落以致数据库中断。这是 managed Postgres 运维成本的主要着手之一。

• 问题 3：Buffer pool 瓶颈。 Postgres 的 shared buffer pool 需要爱戴一个 buffer mapping（内存页 → 磁盘页的映射），在高并发下成为锁竞争的瓶颈。

OrioleDB 的贬责决策

• MVCC 基于 Undo Log：不创建新行，而是原地更新，把旧版块存到 undo log 里。这从根底上摈斥了 bloat。不需要 VACUUM。

• Index-organized tables：数据径直存在索引结构里（访佛 Oracle 的 IOT），摈斥了 Heap 层的稀疏支出，主键查询径直射中数据。

•摈斥 buffer mapping：内存页径直贯穿到存储页，不需要 buffer mapping，读取时不需要原子操作（lock-less）。

• Copy-on-write checkpoints + Row-level WAL：checkpoint 只写修悛改的数据，WAL 按行而非按页记载，更紧凑，更容易并行化。

•内置压缩：页级数据压缩，典型场景下数据库体积缩小 4-5 倍。

性能数据

•只读测试：比 Postgres Heap 快 4x 以上

•读写测试：比 Postgres Heap 快 4.5x 以上

•TPC-C benchmark（50GB 数据）：比 Heap 快 5.5x

•存储空间：压缩后缩小 4-5x

对 Supabase 交易模子的影响

• 这径直改善 gross margin。 要是归并台机器不错处理 4-5 倍的事务量，Supabase 就不错：

•在一样的 AWS 实例上业绩更多用户 → 单元基础设施成本下落

•减少 VACUUM 联系的运维复杂度 → 运营成本下落

•存储压缩 4-5x → 存储成本下落

•为 agent workload 的高频 UPDATE 场景提供可行决策（传统 Heap 下 agent 的不竭 state 更新会产生严重 bloat）

• 同期创造了订价权。 OrioleDB 不是开箱即用的，它需要对 Postgres 核心打约 20 个 patch。这意味着只须 Supabase（以及少数我方 build 的团队）能提供 OrioleDB 的性能。用户不成在 AWS RDS 或 Neon 上使用 OrioleDB。这是一个 只须 Supabase 有的才略。

现时景象

•Beta 7 已发布（2024 年底）

•Supabase 已在文档中提供 OrioleDB 使用指南

•方针是将 patch 上游到 PostgreSQL 核心（Postgres 18+ 可能成为纯 extension）

•现时约束：仅支握 B-tree 索引（不支握 pgvector 的 HNSW），仅支握 ICU/C/POSIX collation

Multigres / Sugu Sougoumarane（2025.06）—— 随性单机约束

Multigres 是 Vitess 的 Postgres 改编版。Vitess 是 YouTube/Google 为了把 MySQL 扩展到全球级别而构建的散播式中间件，面前仍然撑握着 YouTube 的数据库层。Sugu Sougoumarane 是 Vitess 的融合创举东谈主。

Multigres 不是修改 Postgres 自己，而是在 Postgres 前边加一层智能代理，让多个 Postgres 实例在诓骗看来像一个数据库。

Supabase 面前是单节点 Postgres。这意味着：

• 写入瓶颈：通盘写入必须经过归并个 Postgres primary。不管 instance 多大，单节点的写入 TPS 有物理上限。关于 agent 高频写入 state 的场景，这是硬性不休。

• 垂直扩展的成本弧线：当用户需要更多性能时，唯独的遴荐是升级到更大的实例（Micro → Small → Medium → Large → XL → 16XL）。但 AWS 的实例成本不是线性增长——16XL 的成本可能是 Micro 的 100 倍，但性能不会是 100 倍。垂直扩展的单元经济在恶化。

• Enterprise 客户的天花板：大型企业的数据量和并发量可能向上单节点才略。这径直约束了 Supabase 的 enterprise ACV 天花板。

Multigres 的架构

• MultiGateway：接管客户端结合，按 database name 路由到正确的后端

• MultiPooler：每个数据库一个 Postgres 实例 + 结合池

• MultiOrch：管理复制、failover、consensus

• TableGroup：表不错跨多个 Postgres 实例散播，每个 TableGroup 安祥分片

• 在线 migration：跨数据库和 Postgres 版块的无停机移动

• Consensus 条约：保证 leader election 和 failover 自动化

对 Supabase 交易模子的影响

• 解锁 enterprise-scale workload = 解锁高 ACV 客户。 要是一个 enterprise 客户的数据库不错横向扩展到 10 个节点而不是升级到一个超大实例，Supabase 的 enterprise 订价不错从“一个大实例的价钱”形成“一个集群的价钱”——收入上限被根人道地提高。

• 改善多佃户成果。 Multigres 的多数据库管理模式（一个 MultiGateway 后头挂多个 MultiPooler）不错让 Supabase 更高效地管理大批微型数据库。这对 free-tier 和 Pro 用户的成本结构有首要改善——大批一丝据库不错被更高效地打包到更少的物理资源上。

• 为 agent 的 write-heavy workload 扫清进犯。 Agent 每一步齐写 state、checkpoint、memory——这是高频写入。单节点有 TPS 上限，分片后写入不错分散到多个节点。这是 Supabase 从开导者体验公司升级为 agent-native 基础设施的期间前提。

• 创造独家订价权。在 Postgres 生态中，只须 Citus（被 Microsoft 收购，面前是 Azure 专属）和 Supabase 的 Multigres 提供 Postgres-native 散播式才略。Neon 作念了 compute/storage 分离但莫得作念分片。这意味着需要散播式 Postgres 的客户遴荐极少，让 Supabase 有订价权。

现时景象

•Early development 阶段

•有 design partners（具体名单未公开）

•Sugu 和 Deepthi 将在 2026.04 Postgres Conference 演讲

•正在招聘 Multigres 工程师（Go Kubernetes operator、networking）

• Apache 2.0 开源

Hydra / pg_duckdb（2025.12）—— 让 Postgres 作念分析

Hydra 团队融合开导了 pg_duckdb，一个让 DuckDB（列式分析引擎）在 Postgres 里面运行的 extension。随便说：你发一个复杂的分析查询，pg_duckdb 自动判断这个查询顺应用列式引擎处理，然后用 DuckDB 实行——而不是用 Postgres 的行式引擎。对用户来说，体验莫得区别（一样的 SQL、一样的 Postgres 结合），但速率普及了数十乃至数百倍。

同期，Supabase 推出了 Analytics Buckets（基于 Apache Iceberg + AWS S3 Tables），提供 Postgres 接口下的列式存储。

它贬责什么问题

• 搀杂负载的资源竞争。 传统 Postgres 里，要是你同期跑 OLTP（事务处理）和 OLAP（分析查询），分析查询会抢走 OLTP 的 CPU 和 I/O，导致 app 变慢。用户的遴荐平庸是：要么不在 Postgres 里作念分析（导出到 Snowflake/BigQuery），要么隐忍性能下落。

• Supabase 客户的 ARPU 天花板。 要是用户的分析需求必须通过导出到外部数据仓库来中意，那这部分收入就流向了 Snowflake 而不是 Supabase。Supabase 的 ARPU 被约束在“纯 OLTP”的范围内。

对 Supabase 交易模子的影响

• 掀开 upsell 通谈。 Analytics Buckets + Warehouse 让 Supabase 不错向归并个客户同期收 OLTP 用度（Database）和 OLAP 用度（Analytics Buckets + Warehouse）。一个正本只付 $25/月的 Pro 用户，要是初始用分析功能，可能形成 $100-500/月。

• 减少数据出逃。 要是分析不错径直在 Supabase 里作念，用户就不需要把数据导出到 Snowflake。数据留在 Supabase = 收入留在 Supabase。

• 镌汰分析场景的资源挥霍。 pg_duckdb 用列式引擎作念分析查询，比 Postgres 的行式引擎高效得多——一样的分析查询挥霍更少的 CPU 和 I/O。这改善了 Supabase 的 per-query 成本。

• 为 AI/RAG 场景打基础。 Vector Buckets（embedding 冷存储）+ Analytics Buckets（结构化数据分析）+ ETL（一键数据流转）的组合，让 Supabase 不错成为 AI 诓骗的完好数据栈，从 OLTP（app 数据）到分析（用户活动）到 AI（向量检索）全躲闪。这比 pgvector 单打独斗的价值大得多。

现时景象

•Analytics Buckets: Public Alpha (2025.12)

•Vector Buckets: Public Alpha (2025.12)

•ETL (Postgres → Iceberg + Vector) : Private Alpha (2025.12)

•Supabase Warehouse（Hydra 主导）：开导中

BKND（2026.02）—— 业绩新式用户

BKND 是一个轻量级的通用后端系统，基于 Web Standards 构建，不错在职何方位运行（Next.js、Cloudflare Workers、Bun、Node、AWS Lambda 等）。BKND 的创举东谈主 Dennis Senn 加入 Supabase 后，在为 Supabase 构建面向 agentic workloads 的 Lite 居品。

BKND 的核心特征：内置数据管理、认证、媒体存储、workflow builder，支握 MCP server，支握 agent state 管理，支握多种数据库和存储后端。

Agent workload 和传统 web app 的需求互异。 Agent 不需要 Dashboard、不需要漂亮的 UI、不需要文档写得好。Agent 需要的是：轻量（快速启动、低 overhead）、可编程（API-first、SDK-first）、state 管理（agent 的对话历史、任务进程、checkpoint）、MCP 集成（agent 通过 MCP 径直操作后端）。

传统的 Supabase 对 agent 来说太“重”了，一个 managed Postgres 实例 + Dashboard + PostgREST + Realtime + 通盘 feature 的 overhead，关于一个只需要“存一下 agent 的景象然后赓续”的场景来说，是杀鸡用牛刀。

Free-tier 的成本问题。 要是每个 agent 需要一个完好的 Supabase 实例，成本模子不成立，一个用户可能有 10 个 agent，每个 agent 的后端不可能各用一个安祥的 managed Postgres。

对 Supabase 交易模子的影响

• 开辟新的用户类型。 Supabase 面前的用户是东谈主类开导者。BKND Lite 让 Supabase 不错业绩 agent 作为用户。要是每个东谈主有 3-10 个 personal agent，每个 agent 需要一个轻量后端，这个 TAM 是现存阛阓的数倍。

• 优化 agent 场景的资源挥霍。 Lite 意味着更少的 resource overhead per agent。Supabase 不错在一样的基础设施上业绩更多的 agent workload，改善 agent 场景下的 unit economics。

• 补全 MCP 生态。 BKND 内置 MCP server，意味着 Supabase 的 agent 居品不是给 Postgres 加一个 MCP 接口，而是一个 agent-native 的轻量后端，底层连着 Supabase 的数据和认证。这更适当 agent 开导者的情愫模子。

• 为 scale-to-zero 铺路。 BKND 的轻量架构自然顺应 scale-to-zero，agent 不活跃时不挥霍资源。Supabase 的 AI Builders 白标决策还是提供 scale-to-zero 才略。BKND Lite 和 scale-to-zero 结合，不错让 Supabase 以极低的 marginal cost 业绩大批间歇性的 agent workload。

现时景象

•开导中（Dennis Senn 2026.02 加入）

•BKND 自己是开源的（Apache 2.0），将保握开源

•具体居品形式和发布时间未公开

客户访谈响应分析

咱们使用 8 个维度对 12 个不同的 Supabase 客户访谈进行了分析，以下是可视化概览：

驾御滑动稽查完好图文

排版：夏悦涵

The Era of Agent：拾象 AGI 投资知悉

OD体育(ODSports)

深度盘考新一轮模子发布：当智能投入月更期间 | Best Ideas

Agent 期间启示录: 当 Agent 作为新物种加入经济系统

Resolve AI：为什么 AI SRE 领域有望出身下一代 Datadog

为什么「高价值任务」成了通盘 AI Labs 的T0 级政策？｜ 拾象 AGI 备忘录