從開源替代品到百億獨角獸：Supabase 創始人親述 DevTool 爆火密碼

這份材料真正重要的，不只是 Supabase 如何從一個開源數據庫工具成長爲獨角獸，而是它揭示了三個時代變化：

第一，數據庫正在從基礎設施產品，變成開發者生產力產品。

第二，開源公司的競爭核心，已經從“賣軟件許可證”轉向“賣託管、體驗和生態”。

第三，AI Agent 正在取代人類開發者，成爲雲基礎設施新的主要客戶。

下面做一次更高維度的拆解。

一、Supabase 真正賣的不是數據庫，而是“更快地把產品做出來”

表面上看，Supabase 提供的是 PostgreSQL 數據庫、身份驗證、文件存儲、實時訂閱和後端函數。

但這只是產品形態。

Supabase 真正出售的是：

減少開發者從想法到可運行產品之間的時間。

傳統開發流程中，一個創業團隊要自己完成：

1. 創建雲數據庫；
2. 配置數據庫連接；
3. 編寫用戶登錄系統；
4. 設置權限；
5. 搭建文件存儲；
6. 創建 API；
7. 配置實時數據；
8. 處理部署和擴容。

這些工作並不一定創造產品差異，卻會消耗大量時間。

Supabase 把這些重複工作封裝成標準化基礎設施。

因此，它不是單純與數據庫公司競爭，而是在與以下成本競爭：

• 工程師時間；
• 創業公司的開發週期；
• 產品上線速度；
• 技術維護成本；
• 團隊招聘成本；
• 基礎設施出錯風險。

這就是爲什麼“啓動時間從幾分鐘降到幾秒鐘”如此重要。

對於大型企業，節省幾分鐘似乎微不足道。

但對於一個需要反覆創建、刪除、測試幾十個項目的開發者，或者每天生成數千個應用的 AI Agent，這種差異會被成千上萬次放大。

Supabase 的核心價值可以概括爲：

它把數據庫從一個需要學習和配置的基礎設施，變成了一個可以立即使用的產品能力。

二、Supabase 的第一次關鍵轉折：好技術不等於好定位

Supabase 最初強調的是“PostgreSQL 實時引擎”。

這個描述在技術上沒有問題，但在商業上存在一個嚴重缺陷：

用戶無法立刻理解它能替代什麼、解決什麼問題。

“PostgreSQL 實時引擎”是一個技術概念。

“開源 Firebase 替代品”則是一個明確的市場定位。

兩者的差別，不只是文案差別，而是認知成本的差別。

當 Supabase 說自己是“開源 Firebase 替代品”時，開發者立即可以理解：

• Firebase 是誰；
• Firebase 能做什麼；
• Firebase 存在哪些限制；
• Supabase 與 Firebase 的關係；
• 爲什麼值得嘗試 Supabase。

這是一種非常高效的定位策略：

不要一開始教育市場理解一個全新品類，而是借用一個成熟產品的市場認知。

很多創業公司失敗，並不是產品不好，而是用戶無法在十秒內理解產品。

Supabase 的案例說明：

創業公司早期最重要的，不一定是創造一個全新的類別，而是找到一個用戶已經理解的參照物。

類似案例包括：

• “去中心化的 Twitter”；
• “設計師版 GitHub”；
• “企業版 ChatGPT”；
• “開源版 Salesforce”；
• “金融行業的 Bloomberg Terminal”。

這些表達未必能夠永久使用，但在產品早期非常有效，因爲它們顯著降低了市場教育成本。

Supabase 後來當然逐漸超越“Firebase 替代品”的定位，但這個定位幫助它完成了最困難的冷啓動。

三、爲什麼 Supabase 選擇 PostgreSQL，而不是重新發明數據庫

Supabase 最聰明的戰略決定之一，是沒有自己重新創造一種數據庫。

它選擇建立在 PostgreSQL 之上。

這背後的商業邏輯非常深。

1. PostgreSQL 已經完成了最困難的信任積累

數據庫與普通軟件不同。

普通軟件出現問題，可能只是頁面打不開。

數據庫出現問題，可能意味着：

• 數據丟失；
• 交易錯誤；
• 用戶賬戶損壞；
• 財務記錄錯誤；
• 公司業務中斷。

所以企業選擇數據庫時非常保守。

PostgreSQL 已經經過數十年的生產環境驗證。

Supabase 不需要從零證明數據庫引擎是否可靠，而可以直接繼承 PostgreSQL 的信譽、兼容性和生態。

這相當於創業公司不是從空地建樓，而是在一個成熟城市上建新的交通系統。

2. PostgreSQL 不受單一公司的戰略控制

MySQL 曾經被 Sun Microsystems 收購，之後隨着 Sun 被 Oracle 收購，MySQL 的未來方向一度引發開發者擔憂。

PostgreSQL 則不同。

它不是某一家公司的專有資產。

這意味着：

• AWS 可以支持它；
• Google Cloud 可以支持它；
• Microsoft Azure 可以支持它；
• Supabase 可以支持它；
• Neon、Aiven、Crunchy Data 等公司也可以支持它；
• 全球開發者可以持續貢獻。

沒有單一企業完全控制 PostgreSQL，反而形成了更強的長期穩定性。

這是一種典型的公共基礎設施飛輪：

使用者越多，工具越豐富；工具越豐富，採用者越多；採用者越多，企業越願意繼續投入。

3. Supabase 把已有生態轉化成了自己的產品優勢

選擇 PostgreSQL，還意味着 Supabase 可以直接獲得：

• SQL 標準；
• 數據庫擴展；
• ORM 工具；
• 數據分析工具；
• 開發者人才；
• 企業遷移能力；
• 已存在的應用兼容性。

這比開發一種全新數據庫更加高效。

Supabase 的創新，不在數據庫底層算法本身，而在於：

• 如何部署；
• 如何管理；
• 如何連接；
• 如何生成 API；
• 如何處理權限；
• 如何改善開發體驗；
• 如何服務 AI Agent。

這是一種重要的創業思維：

不要在所有層面創新。應該在用戶真正感知價值的層面創新。

四、完全開源爲什麼沒有摧毀 Supabase 的商業模式

很多人對開源存在一個誤解：

“如果代碼全部公開，用戶爲什麼還要付錢？”

答案是：

用戶支付的往往不是軟件本身，而是部署、維護、穩定性、安全性和便利性。

Supabase 的代碼可以開源，但大多數客戶仍然不會願意自己長期管理全部基礎設施。

因爲自行部署數據庫意味着需要承擔：

• 服務器管理；
• 數據備份；
• 數據恢復；
• 安全更新；
• 權限配置；
• 性能監控；
• 容量規劃；
• 故障處理；
• 全球部署；
• 技術支持。

理論上可以自己搭建，不等於經濟上值得自己搭建。

這類似於：

• Linux 免費，但企業願意購買 Red Hat 服務；
• Kubernetes 開源，但企業願意購買託管 Kubernetes；
• WordPress 開源，但大量用戶仍然購買託管服務；
• Git 開源，但企業願意爲 GitHub 付費。

Supabase 的商業模式不是“阻止用戶離開”，而是：

讓官方託管服務比自行維護更加便宜、可靠和省時間。

這是更健康的商業關係。

傳統軟件通過鎖定客戶賺錢。

優秀開源雲公司通過持續提供便利賺錢。

五、Supabase 的真正護城河不是代碼，而是五個相互強化的飛輪

開源代碼本身很難成爲永久護城河，因爲競爭者理論上可以複製。

Supabase 的護城河來自多個飛輪疊加。

1. 開發者體驗飛輪

體驗越簡單，嘗試者越多。

嘗試者越多，反饋越多。

反饋越多，產品改善越快。

產品越好，又會吸引更多開發者。

2. 社區飛輪

開發者在 Reddit、X、Hacker News、GitHub 等平臺討論 Supabase。

社區會生產：

• 教程；
• 模板；
• 插件；
• 問題解答；
• 開源項目；
• 技術文章；
• 視頻內容。

這些內容降低了新用戶的學習成本。

這意味着，社區不僅是用戶羣，也是免費教育體系、支持體系和營銷體系。

3. 生態集成飛輪

Supabase 與越來越多工具集成：

• 前端框架；
• AI 編程平臺；
• 無代碼工具；
• 部署平臺；
• 數據分析工具；
• 身份驗證系統。

集成越多，用戶越容易採用。

用戶越多，其他平臺越願意主動集成。

4. 用量增長飛輪

數據庫業務天然具備用量擴張屬性。

客戶剛開始可能只有：

• 幾百名用戶；
• 幾千條數據；
• 很少的存儲量；
• 很低的請求量。

當客戶業務增長時，Supabase 的收入也可能同步增長。

這種模式的優勢是：

Supabase 不需要每個月重新向客戶銷售，它可以隨着客戶自身成功而增長。

這就是雲基礎設施公司非常有吸引力的地方。

5. 信任飛輪

開發者在個人項目中使用 Supabase。

後來進入創業公司，繼續使用 Supabase。

創業公司成長後，Supabase 隨之進入更大的生產環境。

隨着越來越多成功公司使用，新的創業團隊更願意採用。

YC 創業公司中的高採用率尤其重要，因爲 YC 公司可能成爲未來的大型客戶。

Supabase 在早期抓住創業公司，相當於買下了一批長期增長期權。

六、爲什麼開發者體驗能夠成爲對抗 AWS 的武器

從資源、資本、服務器規模來看，Supabase 不可能與 AWS 正面競爭。

但創業公司不需要在所有維度擊敗巨頭。

它只需要在一個重要維度上做到極致。

AWS 的優勢是：

• 全球基礎設施；
• 產品廣度；
• 企業客戶；
• 可靠性；
• 合規能力；
• 資本規模。

但 AWS 的劣勢也非常明顯：

• 產品複雜；
• 配置繁瑣；
• 控制檯層級多；
• 定價難以理解；
• 服務之間關係複雜；
• 新開發者學習成本高。

Supabase 的機會就在這裏：

AWS 出售的是基礎設施能力，Supabase 出售的是“已經整理好的開發體驗”。

一個創業團隊可能最終仍然運行在 AWS 之上，但它並不想直接操作 AWS 的每一個底層服務。

這類似於 Stripe 與銀行系統的關係。

Stripe 並沒有取代銀行、卡組織和支付網絡。

Stripe 只是把複雜金融基礎設施封裝成了開發者容易使用的 API。

Supabase 對數據庫所做的事情，與 Stripe 對支付所做的事情非常相似：

把複雜基礎設施包裝成簡單、統一、可編程的產品。

七、AI Agent 正在改變 Supabase 的客戶結構

這是整份材料中最重要、最具有未來意義的部分。

過去，Supabase 的主要用戶是人類開發者。

未來，越來越多的數據庫可能由 AI Agent 創建。

這意味着基礎設施行業正在發生一次根本性變化。

1. 人類開發者是低頻用戶，AI Agent 是超高頻用戶

一個開發者可能一天創建一兩個項目。

AI Agent 可以在幾分鐘內：

• 創建項目；
• 生成數據庫；
• 建立數據表；
• 編寫 SQL；
• 創建 API；
• 測試應用；
• 刪除失敗項目；
• 重新生成新項目。

AI 會極大增加基礎設施的創建頻率。

過去，一個創業想法可能需要幾周才能形成原型。

現在，AI 編程工具可能在數小時內生成多個版本。

原型越多，需要的數據庫就越多。

因此，AI 並不一定減少基礎設施需求，反而可能讓基礎設施消費出現爆炸式增長。

這與雲計算早期非常類似。

雲計算降低了服務器創建成本，結果不是服務器需求下降，而是人類創建了更多服務器。

AI 降低軟件開發成本，也可能帶來更多應用、更多數據庫和更多計算需求。

2. AI Agent 不關心漂亮的 Dashboard

傳統 SaaS 產品主要圍繞人類設計，因此強調：

• 圖形界面；
• 按鈕；
• 表單；
• 菜單；
• 可視化操作。

AI Agent 更喜歡：

• API；
• CLI；
• SQL；
• MCP；
• 機器可讀文檔；
• Infrastructure as Code；
• 明確的權限體系；
• 可預測的錯誤信息。

因此，未來雲基礎設施的競爭重點會發生變化。

過去的問題是：

人類使用起來是否簡單？

未來的問題還包括：

AI 是否能夠理解、調用、配置和修復這個產品？

這會形成一種新的產品標準——Agent Experience，簡稱 AX。

就像過去企業重視用戶體驗 UX、開發者體驗 DX，未來還需要重視 AI Agent 體驗。

八、Supabase for Platforms 是比單個數據庫更大的商業機會

Supabase for Platforms 的意義，在於 Supabase 不再只服務終端開發者，而是服務“開發者平臺”。

例如，一個 AI 編程平臺擁有數百萬用戶。

每當用戶創建一個應用，平臺可能需要自動生成：

• 獨立數據庫；
• 用戶身份系統；
• 文件存儲；
• 權限規則；
• API；
• 計算環境。

如果 Supabase 成爲這些平臺的默認後端，它獲得的不是一個客戶，而是一個分發渠道。

這是 B2B2D 模式：

• Supabase 服務平臺；
• 平臺服務開發者；
• 開發者構建最終應用；
• 最終應用服務消費者。

這種模式非常強，因爲 Supabase 不需要逐個獲取數百萬開發者。

它只需要進入幾個高增長 AI 編程平臺，就能批量獲得海量使用量。

Lovable、Bolt、Claude Code 等生態的價值，不只是爲 Supabase 帶來品牌曝光。

更重要的是，它們可能成爲 Supabase 的基礎設施分銷商。

這類似於：

• Intel 通過電腦廠商分銷芯片；
• Stripe 通過電商平臺進入商家；
• AWS 通過 SaaS 公司間接服務最終企業；
• Visa 通過銀行觸達消費者。

真正強大的基礎設施公司，通常並不直接獲得每一個最終用戶，而是嵌入其他產品的底層。

九、全遠程團隊的真正優勢不是節省辦公室租金

Supabase 的遠程模式容易被表面理解爲“沒有辦公室”。

但真正的戰略價值不是節約租金，而是建立了一套高度文檔化的組織系統。

傳統公司大量知識存在於：

• 會議；
• 口頭交流；
• 員工記憶；
• 辦公室關係；
• 私人對話；
• 未記錄的決策。

這種知識很難被複制、搜索和傳承。

Supabase 強調文字化和文檔化溝通，使公司決策逐漸成爲可搜索的數據資產。

在 AI 時代，這種組織方式獲得了新的價值。

因爲 AI Agent 可以索引：

• 歷史決策；
• 技術文檔；
• 產品討論；
• 客戶反饋；
• 設計原則；
• 故障記錄；
• 運營流程。

這意味着 Supabase 過去積累的文檔，不只是公司檔案，而是 AI 時代的訓練和檢索數據。

因此，文檔化組織會形成一種新的組織資本：

一家公司的可用知識，不再只存在於員工大腦中，而是可以被所有員工和 AI 系統共同調用。

未來，公司之間的競爭，很可能不僅是人才競爭，也包括“組織知識可機器讀取程度”的競爭。

記錄越完整，AI 越能協助公司決策。

決策越透明，新員工越容易融入。

知識越結構化，公司越不依賴個別關鍵人物。

十、“錢不能解決核心問題”是一種非常成熟的創業認知

融資可以解決：

• 招聘；
• 服務器成本；
• 市場推廣；
• 產品研發；
• 國際擴張；
• 併購；
• 合規建設。

但融資無法自動解決：

• 產品是否真正有需求；
• 用戶是否願意長期使用；
• 產品定位是否清晰；
• 團隊執行是否高效；
• 公司文化是否健康；
• 用戶體驗是否優秀；
• 社區是否信任公司。

資本只能放大已有系統。

如果系統正確，資本可以加速增長。

如果系統錯誤，資本只會加速浪費。

很多創業公司融資後失敗，是因爲把資本誤認爲產品市場契合。

但融資證明的只是投資人願意下注，並不代表客戶願意長期付費。

Supabase 的資本觀值得學習：

融資不是商業模式，估值不是收入，媒體熱度不是產品價值。

真正決定公司能否長期存在的，仍然是：

• 用戶價值；
• 產品留存；
• 使用量增長；
• 單位經濟模型；
• 技術可靠性；
• 組織效率。

十一、爲什麼創業公司仍然可能擊敗 AWS、Google 和 Microsoft

很多人認爲，大公司有錢、有人、有基礎設施，創業公司沒有機會。

這種判斷忽略了組織結構差異。

大型企業擁有資源優勢，但也存在：

• 決策鏈條長；
• 內部協調成本高；
• 產品線互相競爭；
• 歷史系統負擔；
• 風險偏好較低；
• 難以快速服務小衆羣體；
• 很難圍繞單一用戶體驗做到極致。

創業公司的優勢則是：

• 聚焦；
• 速度；
• 創始人直接接觸用戶；
• 快速迭代；
• 願意服務尚未成熟的市場；
• 願意採用新商業模式；
• 可以圍繞一個羣體建立文化認同。

Supabase 不需要建立比 AWS 更大的數據中心。

它只需要讓開發者覺得：

“使用 Supabase，比直接使用 AWS 更快、更舒服、更符合我的工作方式。”

這已經足以建立一家巨大的公司。

創業公司戰勝巨頭，通常不是依靠更強的資源，而是依靠更好的抽象層。

十二、自駕駛數據庫可能是 Supabase 下一階段最重要的戰略

AI 編程已經大幅降低“構建應用”的難度。

但構建只是軟件生命週期的開始。

真正困難的是長期運行。

應用上線後會遇到：

• 查詢速度下降；
• 索引缺失；
• 數據表膨脹；
• 權限配置錯誤；
• 安全漏洞；
• 流量突然增加；
• 存儲容量不足；
• 數據備份失敗；
• 數據庫連接耗盡；
• 服務宕機；
• 成本失控。

這些問題過去依賴數據庫管理員、DevOps 工程師和安全工程師處理。

未來，自駕駛數據庫的目標是讓系統自動完成：

1. 發現異常；
2. 判斷原因；
3. 提出修復方案；
4. 在權限範圍內執行修復；
5. 驗證修復結果；
6. 保留審計記錄；
7. 必要時請求人工批准。

例如，系統可能發現某個 SQL 查詢掃描了大量數據，於是：

• 分析查詢計劃；
• 建議創建索引；
• 在測試環境驗證；
• 估算性能提升；
• 評估索引成本；
• 自動部署；
• 持續監控效果。

更高級的系統甚至可以：

• 預測容量需求；
• 自動調整資源；
• 檢測異常訪問；
• 修復錯誤權限；
• 自動恢復故障；
• 降低雲成本；
• 預防潛在宕機。

自駕駛數據庫的終局，不只是數據庫自動化，而是：

AI 負責長期運營由 AI 創建的軟件。

AI 創建應用，AI 部署應用，AI 監控應用，AI 修復應用。

人類從直接操作基礎設施，轉向設定目標、權限、預算和安全邊界。

十三、Supabase 面臨的真正風險

Supabase 的發展前景很強，但並非沒有風險。

1. 雲巨頭複製風險

AWS、Google Cloud 和 Microsoft 可以不斷改善開發者體驗，並推出更完整的集成產品。

Supabase 必須保持產品速度和社區親和力，否則體驗優勢會縮小。

2. AI 平臺議價權

如果大量流量來自 Lovable、Bolt 等少數平臺，Supabase 可能對這些渠道產生依賴。

平臺客戶規模越大，議價能力越強。

因此 Supabase 必須同時保持直接開發者生態和平臺合作生態。

3. 數據庫可靠性風險

開發工具出現問題，用戶可能重新運行。

數據庫出現嚴重故障，可能造成不可逆損失。

Supabase 越接近企業核心業務，安全、備份、合規和穩定性就越重要。

4. 開源競爭風險

完全開源會降低用戶被鎖定的程度。

競爭者可以基於相同技術構建託管服務。

Supabase 必須依靠品牌、生態、服務和執行速度，而不能只依靠代碼。

5. AI 自動生成垃圾應用

AI 讓創建應用變得容易，也可能產生大量：

• 低質量項目；
• 垃圾數據庫；
• 濫用行爲；
• 欺詐應用；
• 惡意腳本；
• 短期測試項目。

Supabase 需要處理資源濫用、風控、身份驗證和成本控制。

6. 從開發者工具走向企業市場的挑戰

開發者喜歡簡單、自由、快速。

企業則要求：

• 合規；
• SLA；
• 私有網絡；
• 權限審計；
• 數據主權；
• 客戶支持；
• 長期合同；
• 採購流程。

Supabase 能否在不破壞開發者文化的情況下滿足企業要求，將決定其長期收入上限。

十四、Supabase 案例給創業者的十個實戰啓示

1. 產品定位必須比技術描述更容易理解

不要只說自己用了什麼技術。

要告訴用戶你替代了什麼、節省了什麼、改善了什麼。

2. 建立在成熟基礎設施上，往往比從零發明更聰明

Supabase 沒有重新發明 PostgreSQL。

它重新設計了 PostgreSQL 的使用體驗。

3. 開源不等於沒有商業模式

免費開放代碼，可以換取信任、採用率和生態。

收入可以來自託管、支持、企業服務和用量增長。

4. 速度本身就是產品價值

把八分鐘縮短爲幾秒鐘，並不是小優化。

當操作被重複數百萬次時，這會成爲巨大經濟價值。

5. 社區不是營銷附屬品，而是產品的一部分

社區幫助公司：

• 獲得反饋；
• 發現問題；
• 教育用戶；
• 建立品牌；
• 提供支持；
• 形成口碑。

6. 先服務未來可能長大的小客戶

今天的 YC 小團隊，可能是未來的上市公司。

基礎設施公司越早進入客戶技術棧，長期價值越高。

7. 不要試圖在所有維度擊敗巨頭

選擇巨頭最薄弱、用戶最痛苦的一個層面，做到十倍更好。

Supabase 選擇的是開發者體驗。

8. 爲機器設計產品將成爲新機會

未來產品不僅需要被人類理解，也要被 AI Agent 調用。

API、CLI、MCP、結構化文檔和可編程權限將越來越重要。

9. 文檔是一種資產，而不是行政負擔

文檔化不僅方便團隊協作，也能讓 AI 獲得完整組織上下文。

10. 融資應該用於放大產品價值，而不是掩蓋產品問題

最危險的創業公司，是用融資製造增長假象。

最強的創業公司，是在找到真實需求後，用資本加速。

十五、對 Supabase 的最高層判斷

Supabase 的長期價值，不取決於它是不是“Firebase 的開源替代品”。

真正決定其未來的，是它能否成爲：

AI 原生應用時代的默認數據與後端基礎設施。

如果未來數千萬個應用由 AI Agent 創建，那麼這些應用仍然需要：

• 數據庫；
• 身份系統；
• 權限；
• 文件存儲；
• API；
• 實時同步；
• 自動運維；
• 安全與審計。

AI 可以降低寫代碼的成本，卻無法消滅數據基礎設施。

恰恰相反，應用數量越多，基礎設施需求可能越大。

因此，Supabase 所處的並不是一個被 AI 淘汰的行業，而是一個可能被 AI 極大擴張的行業。

它未來最重要的競爭，不再只是 Supabase 對 Firebase，也不只是 Supabase 對 AWS。

更深層的競爭將是：

誰能成爲 AI Agent 最容易理解、最容易部署、最容易運營、最值得信任的數據庫平臺。

誰贏得 Agent，誰就可能贏得下一代軟件基礎設施。