--- author: Best Partners TV date: '2026-11-06' guest: '' layout: post.njk source: https://www.youtube.com/watch?v=jX1-1iR-HBA speaker: Best Partners TV tags: - database - ai-agent - open-source - software-engineering title: Supabase联合创始人对谈YC合伙人：AI代理时代的数据库与软件开发范式转变 summary: 节目探讨了Supabase在AI浪潮中的高速增长，约70%新活动来自AI代理。嘉宾与YC合伙人讨论了代码优先转型、开源价值、个人数据库兴起以及面向代理的错误信息优化等行业变革。 insight: '' draft: true series: '' category: ai-application area: tech-engineering project: [] people: [] companies_orgs: - Supabase - Y Combinator products_models: - PostgreSQL media_books: [] status: evergreen --- **大飛**: 大家好，這裡是最佳夥伴，我是大飛。試想一下，如果每個人都能將腦海中的想法變成軟體，世界會是什麼樣子？ Supabase 聯合創始人兼執行長 Paul Copplestone 最近在 Latent Space 播客節目中花了 49 分鐘。Supabase 是一個基於開源 PostgreSQL 的後端平台，如今已成為 CloudCode 和 Codex 等代理程式的預設資料庫。本次對話的主持人是 Garry Tan、Harj Taggar 和 Jared Friedman，他們都是 Y Combinator 的核心合夥人。他們談論的不僅僅是一家普通的資料庫公司，而是整個行業正在發生怎樣的變化，因為人工智慧正在將軟體開發人員的門檻降低到零。 讓我分享一些數據：Supabase 目前有 1,300 萬名註冊用戶，而 12 個月前這個數字只有 300 萬。它管理著近 5,000 萬個資料庫，而去年同期為 800 萬個。每週創建超過 100 萬個資料庫，今年的收入預計將翻兩番。最值得注意的是，約 70% 的新活動來自人工智慧代理；保羅將此描述為一個轉折點。 ### 代理時代的轉捩點與產品演進 那麼，這個轉捩點是如何出現的呢？Garry 提出了一個觀察：加入 YC 的新創公司在第一天都會收到一件 T 卹，上面寫著「創造人們想要的東西」。但現在，應該改為「製作經紀人想要的東西」。Supabase 就是一個完美的例子。 Paul 認為成長主要來自兩個方向：首先，軟體工程師在開發過程中受到的限制越來越少；其次，越來越多的非工程師出身的創造者參與其中。過去需要軟體工程背景才能開發的功能，現在完全沒有任何工程經驗的人也可以在 Supabase 上進行開發。 這也與 Supabase 產品本身的演變有關。保羅說他們經歷了三個階段。最初，它是一款以主機為主導的模型，其靈感來自 Airtable。他們當時想，為什麼不開發一款介面類似 Airtable 但後端採用 PostgreSQL 的產品呢？後來，大約在 2021 年，他們轉向了 API 優先的方法，因為客戶表示：「我們想要創建許多資料庫，我們需要一個 API 來完成所有這些工作。」事實證明，到 2024 年，當 Bolt.new 等產品在這些技術之上構建時，這被證明是正確的舉措。 Supabase 能夠取得今天的成就，也得益於它抓住了幾個產業浪潮。哈吉問保羅，他是否受到了該領域前輩的啟發。Paul 提到 Parse 和 Firebase 都是後端平台。其中一家被 Meta 收購，另一家被 Google 收購。從某種意義上說，他們為 Supabase 鋪平了道路；人們意識到他們不必使用三大雲端服務提供者的資料庫，獨立的資料庫公司也能取得成功。Heroku 提升了 Postgres 的受歡迎程度，儘管當時 Postgres 還處於早期階段，可擴展性有限；而 MongoDB 則以某種方式讓所有人相信 NoSQL 是儲存資料的絕佳方式。這些浪潮一波接一波地襲來，Supabase 很幸運地捕捉到了其中幾波。 ### 從控制台到代碼優先與開源優勢 現在，它正處於浪潮的中心，但今年情況發生了變化。Paul 說，實際上已經沒有人再訪問控制台了——如果沒有人使用控制台，代理商該如何發展？他向團隊發送了一份產品備忘錄，指出 Supabase 必須轉向代碼優先和 Git 原生。如果控制台中存在某個功能，那麼它基本上必須能夠透過程式碼同步；從本質上講，這就是基礎設施即程式碼。因此，他們重新設計了命令列工具和其他元件，以便它們可以在 shell 和程式碼中工作。Paul 補充說，成為大型語言模型的首選產品為他帶來了顯著的好處。 然後是開源軟體的作用；很難說如果沒有它會發生什麼，但在他看來，這極為重要。Supabase 的所有功能都是開源的；他們支援 Postgres 生態系統中的現有工具，例如 Prisma，並幫助維護這些工具，這使他們能夠接觸到許多社群。G 非常準確地觀察到，代理人特別喜歡開源軟體，因為當出現問題時，他們可以直接查看原始程式碼，而不是被困在牆後，對發生的事情一無所知。 什麼？此外，安全問題也變得越來越重要；許多企業希望查看原始碼以驗證安全性，但成長不僅來自工程界，更來自創作者群體。 ### 非工程背景創作者的興起與個人軟體 Paul 說，今年一個有趣的現象是，他們的漏斗頂端註冊用戶數量正在快速成長。通常情況下，這種情況會導致活化率和轉換率下降，但今年所有指標都呈現上升趨勢。原因是模型在開發方面變得越來越好，使得沒有傳統軟體工程背景的人也能參與產品開發。 Hagit Tagar 分享了一個真實案例：一位金融科技創辦人以超過 10 億美元的價格退出了公司。Hagit 本人一直更傾向於產品方面；他本科學習的是數學，可以編寫一些 Ruby 腳本，但他總是需要工程師來開發軟體。現在，他自己也從事一些副業項目，例如為自己的個人財務、資產負債表和追蹤工具建立相當複雜的軟體，從零開始連接到銀行 API——兩年前，這種軟體是根本不可能建構出來的。 保羅說，這些領域專家是理想的創作者。像他這樣的開發者往往從開發者的角度看待問題，但領域專家卻清楚知道他們特定領域還有哪些問題尚未解決。現在，他們可以直接投入其中，而無需先說服其他人加入。他提到了 Supabase Select 大會上的一個例子：一位來自巴西、大約 50 歲的出租車司機，僅憑手機就開發了一款完整的叫車應用程序，本質上是面向當地市場的迷你版 Uber。 G 回憶起 YC 內部的一次關鍵轉變。從 2022 年到 2025 年，YC 特別強調了技術聯合創辦人的重要性，但在過去一年裡，他們開始表示，真正的關鍵在於創辦人。發展能力已成為任何人隨時都可以利用的東西；更難的是知道該建造什麼。你能想像過去有多少東西沒有建成嗎？人們知道有問題，也有買家，但即便如此，他們也無法說服工程師建造它。而這些創作者最終都需要一個資料庫。 Garrett 提出了一個反思資料庫歷史的想法：過去，世界上只有數量有限的大型資料庫，這些資料庫由大公司營運。Supabase 最初創立時，讓每個人都能輕鬆創建資料庫的想法似乎幾乎是無稽之談；如果你不會編程，你能用資料庫做什麼？在人工智慧出現之前，這確實太費力了，但現在情況不同了。 Haki 分享了他的經歷；他是 YC 的聯合創始人，最近一直在開發自己的個人軟體，這源於他對 OpenAI 的日益痴迷。有一段時間，他堅持不使用資料庫，並且想把所有內容都放在 Markdown 中。然而，在某個階段，資料庫變得有用，甚至成為必需品。他稱這套系統為“控制塔”，涵蓋了他生活的方方面面。內部有一個介面，可以對他的所有電子郵件進行分類和處理，這樣他就不用手動查看收件匣了，此外還有財務支出追蹤和健康記錄。 有趣的是，在他看來，對於一個僅為個人打造的應用程式來說，其財務模組至少與 Mint 或 Monarch 等產品不相上下，並且在某些方面甚至更好，因為它使用了高度個人化的背景資訊。例如，它可以在他的通訊錄中找到姓名，找出這個人是誰，並且能夠理解交易內容並對其進行正確分類，這在過去……足以支撐一家公司，但現在他可以自己建立一個，而無需向任何人尋求幫助。 最簡單的用法甚至不需要介面。Hagi 提到有一個文件上傳門戶，任何文件都可以透過電子郵件轉發，或直接拖曳到介面中。然後，代理人確定它是什麼，它與他的生活有何關係，以及應該如何處理。所有這些數據都儲存在 Supabase 上。他說，Supabase 最終會將他生活中的所有數據集中到一個地方。一年前，他從未想過自己需要個人資料庫，因為當時這毫無意義，但現在它已成為他最寶貴的資產。 保羅說他們看到很多人都這樣做；金融和健康是人們最希望擁有自己數據的兩個領域。Hagi 強調，Supabase 在這裡的價值在於其權威記錄——資料庫本身。使用者希望擁有自己的資料庫，然後在資料庫之上建立各種應用程式和代理，而不是將所有內容都保存在別人的資料庫中。 ### 規模化挑戰與架構調整 這件事的長期影響可能超乎想像。Paul 提到了一個大規模的預測：GPT 每週有 12 億用戶。如果每個人每個月都想推出新產品，那每個月就需要 12 億個資料庫。他們目前每週生產 100 萬件產品，所以差距仍然很大。因此問題來了：這真的可以用 Postgres 實現嗎？或者他們需要開發自己的資料庫引擎？ 保羅說他認為這是偏有可能的，但需要做出一些調整。他們最近收購了 Deno，其架構與 Postgres 和 SQLite 相容，因此他們將提供一個名為 Supabase Spark 的服務層。基本上，它是為新創公司工作負載而設計的。概念保持不變：從相同的體驗開始，逐步擴展到 PB 級。口號是「從原型到 PB 級」。作為一家公司，他們必須確保服務到每一位顧客。即使業務不斷發展壯大，規模不斷擴大，他們也必須確保用戶擁有良好的體驗。 萩指出這很有趣；人工智慧時代之前的典型資料庫公司都認為自己的未來會成為像 Oracle 這樣的公司，因此他們必須盡快進入企業市場，而 Supabase 則傾向於 SQLite，似乎朝著相反的方向發展。Paul 表示他們正在同時進行這兩項工作，使用兩款產品來覆蓋兩端：Postgres 可以擴展到 PG，而 Deno 可以覆蓋原型和 SQLite 工作負載。按照這樣的成長速度，他們需要不斷招募更多的人。即使借助人工智慧，這仍然是一個真正的挑戰，但也是一個有趣的挑戰。 ### 軟體工程的實踐變革 軟體工程界的這種轉變更加直接。格雷厄姆提到一項調查，最初只有 10% 的工程師使用編碼代理編寫 80% 的程式碼，但僅僅六個月後，這個數字就躍升至 60%。這是怎麼發生的？Paul 表示他們沒有嚴格的內部人工智慧使用政策；他們提供任何人們想要使用的工具。這些模型現在運行得更好，完成的工作更多，因此採用率正在迅速增長。 此外，工程師們正在建造的不僅僅是使用自然語言程式設計製作的小部件，而是相當複雜的系統。隨著他們轉向人工智慧生成的程式碼，他們實施了廣泛的測試，並引入了許多測試工具，這對於確保最終輸出的高品質非常有幫助。Graham 補充說，YC 新創公司也看到了這種趨勢：測試數量激增，程式碼審查也在不斷發展。 今年早些時候，開發者可能認為結果並不理想，但現在他們發現這些模型實際上已經有所改進，並且真的可以用來建立令人驚嘆的東西。納維-斯托克斯方程式等領域的進步正在讓市場相信可以開闢新的領域，但保羅仍然提醒我們，改變不會自動發生。 他最推崇的建議就是：一定要使用自己的產品。他現在親自使用 Claude，經常透過電話與它對話，一邊聊天一邊問：「你能做出這些改變嗎？」他給自己定了一條簡單的規則：除非需要驗證它是否真的能正確構建某些東西，否則他不會去看程式碼，也不會檢查架構。 他最近買了一個名為 openusd.dev 的網域。由於確實存在一種名為 OpenUSD 的文件格式，而他又喜歡收集域名，所以在皮克斯和英偉達等公司突然宣布推出 OpenUSD 之後，他認為自己應該利用它，但一直沒有時間。於是，他開始和克勞德聊天，克勞德開發了一個開發者的網站，其中包括生態系統資訊和其他內容。 一天的工作即將結束，他正準備睡覺時，又給克勞德打了個電話，說道：“我不喜歡目前生態系統和用例之間的連接方式；這種信息架構不太好。你能提些建議嗎？”克勞德提出了一個建議，然後他說：“好的，執行它們。”二十秒後，克勞德說：“甚至這樣了，他不比再親自去做以前那些傳統上需要他親自完成的任務了；他一直在聊天。保羅說，這讓他感覺自己彷彿看到了未來。 Gaurav 用這個例子有力地說明了這一點，他說這就像一股不可阻擋的力量撞擊一個不可移動的物體。模型的功能正沿著拋物線曲線飛速增長，而懂得如何利用模型真正影響社會的人數卻基本保持不變。 當 Boris Chernony 做客 Latent Space 播客時，他描述了程式設計的未來：你可以像朋友一樣與 Claude 聊天，而無需了解評估或其他技術細節，Claude 會自動想辦法實現你的想法。Gaurav 開玩笑地補充說，將來我們可以讓代理商參加 Supabase 大會，聽聽產品功能更新，然後再回去將這些功能整合到程式碼庫中。 ### 面向代理的設計與動態評估 保羅提到他們真的應該專門為經紀人舉辦一次會議，但他同時也承認，使用經紀人會帶來一些問題，尤其是當他逐漸將自己的日常日程安排和客戶關係管理系統移交給某個特定的經紀人時。如果他以後想切換或連接其他代理，他的數據可能會被鎖定，所以他正在慢慢地將這些數據轉移到任何代理都可以訪問的中立位置。 這背後涉及到一些產品設計方面的問題；Gaurav 詢問 Supabase 在使產品對代理商更加友好方面做了哪些努力，例如提供錯誤訊息。保羅說，他在波士頓參加 dbt Labs 的活動時驚訝地發現，事實並非如此顯而易見。傳統上，開發人員收到的錯誤訊息通常是像「500」這樣的簡單提示，但現在您希望代理能夠自我修正，因此錯誤訊息必須明確地告訴他們如何修復錯誤或閱讀哪些文件來解決問題。 很多工作其實只是選擇一個用例，然後不斷改進錯誤訊息，直到你想要做的事情能夠始終在第一次嘗試時就成功為止。保羅也提到，贏得代理商的信任有兩個階段：首先，被模型選中；其次，確保他們在遇到困難時不會轉而使用其他產品，而這種情況是不可避免的。所以你只需要給他們工具，讓他們自己解決問題。 Supabase 還建立了一個評估網站，用於測試不同模型的性能，並找出哪些模型最擅長使用 PGroonga，這對整個行業來說都很有價值。因此，相當一部分工程精力都花在了測試具體的使用場景上，而不是僅僅開發功能。 說到評估，Gary 分享了 JBIN 的範例。這是他所建構的個人知識系統，背後有著有趣的開發故事。最初，使用 RAG 感覺就像為代理人建造工廠，把每一次 LLM 通話視為既昂貴又極其危險的事情，需要格外謹慎。後來，當他開始使用 opencloud 時，感覺完全不同了，就像從工廠搬到了埃薩倫冥想中心。所以他說，如果你認為人工智慧很聰明，而且它不想傷害你，你就應該讓它工作，並給它數據和能力。 JBIN 擁有 50 萬份 MD 文件，記錄了 Gary 過去的通訊記錄；他說，一百萬大約相當於三本《哈利波特》小說，這對於人類來說已經是非常強大的工作記憶了。大多數人一次最多只能記住七件事，上下浮動兩件。但即使是一百萬個代幣也有其局限性；例如，代理人可能在任何特定時刻只需要其中的兩頁。那麼，如何將這兩頁內容融入脈絡中呢？這是一個檢索問題。這就是為什麼 JBIN 提供 Supabase 託管服務，包括 RAG 檢索。 其 JBIN 儲存庫有 40 個不同的評估類別，採用了 CPY 概念：一個代理始終運行，負責提出新的評估類別，而另一個代理則運行以遍歷所有類別，自動研究並嘗試每天提高評估分數。任何能夠改進評估指標的變更都會預設合併到主分支中，而任何嘗試過但沒有成功的方法都會寫入 Markdown，並解釋其失敗的原因，然後進行歸檔。 資料庫方面呢？這時，他提出了一個有趣的想法：資料庫本質上是資料檢索機制，你可以在其中添加索引，以特定方式搜尋資料。但是，如果您反覆搜尋相同的數據，每次都需要 10 秒鐘，為什麼不讓代理不斷嘗試建立新索引或找到最合適的索引，從而將返回時間縮短到 1 秒以內呢？這使得代理能夠不斷循環並建立最適合特定搜尋的資料結構。一旦程式碼產生能力足夠強大，動態檢索顯然將成為常態。 ### 給未來的建議 最後，保羅給那些想要跟上時代變化的人們提出了一些建議。 首先，真正使用自己的產品；沒有什麼比在使用自己的工具時遇到問題更直接的回饋了。 其次，要預留一些額外的容量。他們試圖與該領域的關鍵人物建立合作關係；這種生態系統合作很有幫助，因為合作夥伴可以分享他們正在開發的東西。同時，他們努力為團隊留出一些餘地——儘管這非常困難——這樣當合夥人有新想法時，他們就可以嘗試一下。增加投資並不能保證成功；有些想法聽起來很酷，但經過測試後卻失敗了，而真正成功的嘗試最終讓他們能夠一起乘風破浪。 第三，選擇耐用的場地。保羅提到他聽說資料庫已經存在了 50 年，而且在他看來，資料庫還會存在 50 年。無論人工智慧最終如何發展，資料庫都將繼續存在。他很欣賞 Strapi 的例子，其創辦人一直關注新的發展方式。Supabase 並沒有試圖提供所有答案；他們只是想確保自己始終能夠適應最好的情況。如今事物變化如此之快，以至於這個時間跨度變得非常短。 正如他在採訪開始時所說：「我非常期待 2027 年。只要我們能保持這個速度，避免一些意外情況，對很多人來說，這應該會是一段有趣的旅程。」 感謝觀看。我們