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 兼容层重叠于其漫衍式存储基础设施之上的工程智商，金沙JinSha(中国)娱乐网入口并可在单项 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 投资知悉

金沙JinSha(中国)娱乐网

深度究诘新一轮模子发布：当智能参加月更期间 | Best Ideas

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

Resolve AI：为什么 AI SRE 边界有望降生下一代 Datadog

为什么「高价值任务」成了整个 AI Labs 的T0 级计谋？｜ 拾象 AGI 备忘录