Supabase 收購 Turso，因為 AI 代理需要每個任務一個資料庫
Supabase 在 10 月 2 日宣布，該公司已募得 1.5 億美元，並將收購以 SQLite 為基礎的資料庫公司 Turso。這輪募資由新加坡的 GIC 領投，Alphabet 的成長基金 CapitalG、IronArc 與 SquarePeg 參與。收購價格未公布，而募資公告不應被解讀為收購價。
這筆交易底下的架構押注才是有趣之處。Supabase 的事業是圍繞 Postgres 建立；Postgres 是為共用單一一致儲存庫的應用程式所設計的關聯式系統。Turso 從頭改寫 SQLite，移除了單一寫入者限制，接著透過無磁碟架構提供服務，並將預寫式日誌（write-ahead log）保存在 S3 上。結果是一種可依需求、針對每個代理佈建的資料庫，成本遠低於為每一個代理啟動一台機器。
Supabase 引用的數字
Supabase 表示，現在每月新增超過 100 萬名使用者，以及約 400 萬個資料庫。該公司回報，平台上約 70% 的新資料庫是由代理或 AI 驅動工具建立。它在 6 月時回報資料庫數量較前一年同期成長 600%，並表示代理已負責大多數新部署。該公司稱有超過 1,300 萬名開發者使用該平台。
這些都是公司自行公布的採用數據，而資料庫建立數與營收或留存率並不是同一種衡量指標。代理為某項任務啟動、並在一小時後捨棄的資料庫，仍會計入那個每月總數。這些數字真正顯示的是需求曲線的形狀：資料庫建立量的成長速度，比建立它們的人類數量更快；這正是每個應用程式一個資料庫的模式正承受壓力的訊號。
為什麼每個代理一個資料庫會打破舊有的成本算式
基礎設施的單位正在改變。當人類開發者打造應用程式時，一個資料庫服務許多使用者，而佈建它的成本會由一個長期專案攤提。當代理執行任務時，它可能需要自己的暫存儲存庫來保存狀態、記憶或中間結果，而且可能只需要幾分鐘。
在傳統受管資料庫模式下，為每個代理佈建一個執行個體，在那種規模下並不可行。配置伺服器、設定與計費的開銷，會讓其中執行的小型工作負載價值相形見絀。Turso 的賣點是，建立資料庫幾乎不費成本，閒置時也幾乎不產生費用，因此啟動 100 萬個資料庫是正常操作，而不是一筆需要特別記帳的事件。
Supabase 引述的 Turso 客戶名單包括 Superhuman、CTO.new、Sauna.ai 與 Mastra。Turso 創辦人 Glauber Costa 將加入 Supabase，擔任代理服務（Agentic Services）負責人，共同創辦人 Pekka Enberg 與團隊其餘成員也將一同加入。
如果你已經在使用 Turso，有一個細節值得注意：該公司較早期的 libSQL 分支與較新的 Rust 引擎是不同的實作，兩者的功能集並不相同。Turso 在 2025 年 1 月的重寫公告中說明了這段轉換。團隊應先確認自己的部署執行於哪個引擎，再假定行銷頁面上列出的功能在正式環境中可用。
這筆收購瞄準的競爭對手
這樁收購也釐清了 Supabase 的競爭對象。其付費方案包含身分驗證、儲存、邊緣函式、即時訂閱與向量搜尋，這讓它在受管後端市場中與 Firebase、MongoDB Atlas 和 AWS Aurora 競爭，而不是只與單一資料庫供應商競爭。
這些對手在代理層各有不同弱點。Firebase 將開發者綁在文件模型與 Google 雲端上。MongoDB Atlas 能彈性地為資料建模，但它是按叢集收費，而非按代理工作單位收費。Aurora 功能強大，但在小規模時所費不貲，其佈建方式也不適合只存活幾分鐘的任務。
Turso 的貢獻在於提供盡可能最小的儲存單位。它提供並行寫入、原生向量搜尋與在瀏覽器中執行，並支援裝置與雲端之間的嵌入式複製。最後一項能力對某類部分在使用者機器上執行的應用程式很重要；在這類情境中，往返雲端資料庫的做法並不適合問題的形態。
升級路徑是商業機制。一個專案若從單一 SQLite 資料庫起步，成長為真正的應用程式後便會遷移到 Postgres，並隨之轉入付費方案。Supabase 的論點是，在代理建立專案的那一刻就抓住它，比之後再獲取開發者更便宜。
募資歷程本身就是一種訊號
這輪募資距離 Supabase 於 2026 年 6 月完成 5 億美元 F 輪融資僅四個月；該輪由 GIC 領投，投後估值達 105 億美元。該輪之前，則是 2025 年 10 月以 50 億美元估值完成的 1 億美元 E 輪融資。如今總募資金額已突破 10 億美元大關。
這麼快再次募資，顯示該公司想要的可能是資金，也可能是新聞聲量；新聞稿指出，這輪部分資金用於為員工提供流動性。在這個階段，為員工安排次級交易很常見，也值得與公司實際投入營運的現金分開看待。
策略邏輯比財務邏輯更清晰。Supabase 想成為開發者或代理在專案需要後端時第一個求助的地方。如果這類專案最早期的版本，是由代理建立的一個小型 SQLite 資料庫，那麼掌握建立的那一刻，就等於在競爭對手看到專案之前先掌握了這段關係。從那裡開始，當應用程式的規模超出輕量層級時，Supabase 提供升級到標準 Postgres 的路徑。Turso 將繼續以平台形式運作，其程式碼庫也維持開源。
整併模式
Supabase 並非唯一採取這步棋的公司。Restate 本月在 Singular 領投下募得 2,000 萬美元 A 輪資金，用於打造可持久運作的基礎設施，避免長時間執行的代理工作流程中途失敗。LlamaIndex 推出以結構描述為基礎的文件擷取工具，瞄準代理資料管道。這些交易共同的主題是：代理底下的管線正在成為一個產品類別，而過去被視為事後才想到的部分，如今都獲得了資金。
對開發者而言，實際問題是會有什麼改變。現有 Supabase 使用者得到的說法是他們不會感受到任何差異；對一個如今在同一屋簷下運行兩種引擎的平台來說，這是正確答案。更具影響力的轉變在於預設值。如果 Postgres 與 SQLite 都共存於同一個生態系，兩者之間的選擇就變成取決於工作負載形態，而不是供應商；便宜選項也能在代理需要的那一刻立即取得，而不必等上一輪採購流程。
仍未解答的是，這樣的經濟模式是否成立。每個代理一個資料庫的模式要能成立，前提是儲存、佈建與支援成本必須低於客戶願意支付的價格，而且這些資料庫中要有足夠數量成長為付費的正式工作負載。Supabase 押注答案為是，並賭上值得留下的專案都會從小規模開始。