Supabase 如何成為 AI 代理的首選後端？

我第一次見到 Paul Copplestone 和 Ant Wilson 是在新加坡，當時他們剛結束 YC S20 孵化器，是該期最受矚目的新創公司。六年後，我們終於邀請他們上播客！這是他們首次共同參與播客，分享如何將一家開源、完全遠端運作的公司從零發展到估值百億美元。

這個標題正是我自己想了解的問題：為什麼 AI 代理喜歡 Supabase？市面上有許多託管資料庫，Postgres 託管服務競爭激烈。對模型而言，熟悉度確實有助於推廣，但這無法完全解釋將生成式應用程式轉化為可運行實體所需的所有工作。然而，當我運行我的前沿 AEO 追蹤器時，從 Astra 到 Fable 再到 Muse，幾乎所有前沿模型都將 Supabase 列為應用程式後端的首選（並在託管資料庫中具有競爭力）。

在 Select 大會上，Supabase 將其發布內容分為「建構」、「營運」和「擴展」三大類。讓我印象深刻的是那些出乎意料的實用功能：無需 Docker 即可啟動本地後端、將所需的資料庫架構保存在 Git 中，以及在資料庫旁運行運算。這些功能都消除了開發者多年來一直在做的工作，而 AI 代理讓這些摩擦變得更難以忽視。

「為 AI 代理提供一個可讀的後端」是我最喜歡的開發者工具發布，它讓我思考：我今天當然想要這個。無需 Docker 即可在本地運行 Supabase 的新 Alpha 運行時就是其中之一。我使用 Colima 而非 Docker Desktop，即使如此，從工作資料庫的路徑中移除另一個依賴項仍然是受歡迎的。

本地設定只佔人類開發者每週工作的一小部分；但對於重複建立和測試環境的 AI 代理來說，它會一次又一次地遇到這個問題。

聲明式架構是更大的概念。熟悉的 SQL 工作流程會累積歷史：建立架構，然後遷移、遷移、再遷移。聲明式表示法為 AI 代理提供所需狀態的描述，這些描述存在於 AI 代理可以檢查和編輯的檔案中，與應用程式並存。在評論中，我將其比作資料庫的 Terraform 時刻。

將所需狀態放入 Git 中，AI 代理就可以讀取、更改、分支並針對其進行工作，作為儲存庫的一部分。人類也獲得了同樣的優勢：無需重建其整個歷史，後端變得更容易理解。

這是我最喜歡 AI 代理友善方向的部分。這些改進是我作為開發者本來就想要的。讓它們對 AI 代理有用，為團隊提供了完成這項工作的另一個理由。

「運算值得更多關注」我認為 Supabase Compute（目前處於私人 Alpha 階段）可能被低估了。應用程式需要一個地方來執行其工作，也需要一個地方來儲存結果。一旦你有了資料庫，你仍然需要一個地方來運行處理文件分塊、生成嵌入或執行其他長時間運作工作的程序。

Paul 和 Ant 討論了在資料庫附近運行容器。這彌補了應用程式啟動和營運之間的差距：需要配置、連接和向 AI 代理解釋的獨立服務更少。邊緣函數仍然有用，但它們無法涵蓋所有工作負載。

營運方面也很重要。日誌、檢查、連接和上下文有助於 AI 代理理解它正在改變什麼。一個可以發出 SQL 的模型仍然需要知道資料庫包含什麼、應用程式如何使用它，以及當某些東西失敗時發生了什麼。Supabase 的營運發布值得與新的建構方式一起閱讀。

「從原型到 PB 級」創辦人表示 Supabase 每月啟動約五百萬個資料庫。他們正在思考如果 AI 代理將這個數字推向數十億個應用程式會發生什麼。同時，現有客戶正在發展為更大的工作負載。服務更多小型資料庫和支援客戶日益增長的龐大資料庫是不同的工程問題。

這有助於解釋「擴展」發布的廣度：OrioleDB、Multigres 和 Turso 的收購。對話深入探討了新「從原型到 PB 級」定位背後的工作，包括 Postgres 的可靠性以及擴展和橫向擴展所涉及的選擇。

Paul 和 Ant 的一個觀察對於任何開發工具的建構者來說都特別有趣：隨著 AI 驅動的使用量增長，他們表示啟用和轉換率都有所提高。他們的解釋是，AI 代理可以引導用戶從註冊到工作設定，一氣呵成。用戶無需在看到應用程式運作之前弄清楚每個配置步驟。

我們還討論了幫助 Supabase 成長的迷因和社群、開源採用和企業銷售，以及 AI 代理是否會趨同於相同的應用程式模式。但我也希望這一集能捕捉到創辦人之間的化學反應。這是一個機會，可以聽到 Paul 和 Ant 一起思考產品，並了解一個讓 AI 代理看起來輕鬆的後端背後有多少工作。