Supabase：百億美元估值，vibe coding 的默認後端？

01.

點解要關注 Supabase

Coding Agent 係科技史上增速最快嘅新品種

1. Supabase 同時踩中兩條 AI 時代嘅大趨勢，就係 Postgres 作為 AI 嘅心智語言，同埋 coding 作為 AI 需求最大嘅爆發點。

Coding 係 AI 而家最大嘅浪潮同絕對嘅主線，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 個月升咗 7 倍，已經超過 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 喺生成代碼時表現出三項差異：

• 代碼產出量比人類高大約 1000 倍以上

• 絕大多數產出屬於 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 兼容層疊加喺佢哋嘅分佈式存儲基礎設施之上，仲可以在單項 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，數據量 <100GB、花費 <20 萬美元，認為太新，唔適合關鍵基礎設施

如果只考慮應用開發者呢個羣體嘅擴張同 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 快 4 倍以上

• 讀寫測試：比 Postgres Heap 快 4.5 倍以上

• TPC-C benchmark（50GB 數據）：比 Heap 快 5.5 倍

• 存儲空間：壓縮後縮小 4-5 倍

對 Supabase 商業模型嘅影響

• 呢個直接改善 gross margin。 如果同一部機器可以處理 4-5 倍嘅事務量，Supabase 就可以：

• 喺同樣嘅 AWS 實例上服務更多用戶 → 單位基礎設施成本下降

• 減少 VACUUM 相關嘅運維複雜度 → 營運成本下降

• 存儲壓縮 4-5 倍 → 存儲成本下降

• 為 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 客戶訪談進行咗分析，以下係可視化概覽：

左右滑動睇完整圖文

 排版：夏悦涵

延伸閲讀

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 兼容層疊加於其分佈式存儲基礎設施之上的工程能力，並可在單項 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，數據量 <100GB、花費 <20 萬美元，認為太新不適合關鍵基礎設施

若僅考慮應用開發者這一羣體的擴張和 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 客戶訪談進行了分析，以下是可視化概覽：

左右滑動查看完整圖文

 排版：夏悦涵

延伸閲讀