What Happens When Everyone Can Build Software

Supabase 共同創辦人暨執行長 Paul Copplestone 認為，下一波資料庫客戶會是一般的「builder」——具備領域專業、手上又有 AI 編碼代理的非工程師；他甚至預期，未來每個人都可能擁有一座個人資料庫，存放自己的健康、財務與人際關係資料。本集訪談主要圍繞 Supabase 的成長與產品策略：它如何從一家儀錶板公司，轉型為 API 公司，再變成專為代理打造的程式碼優先（code-first）公司；它打算如何做到每週新增一百萬座資料庫（甚至每月十億座）；以及它如何重新設計錯誤訊息與評估機制（evals），讓代理能自行排錯。標題所說的「人人都有一座資料庫」確實是貫穿全集的一條主線，但只佔據部分篇幅；其餘內容則是一趟代理優先產品設計、Postgres 擴充套件與小型 AI 槓桿軟體公司經濟學的導覽。

與 Copplestone 對談的是 Y Combinator 主持人 Jared Friedman、Harj Taggar 與 Mark Mirchandani。討論建立在 Supabase 自家的數字上——1,300 萬註冊數、約 5,000 萬座代管資料庫、營收成長 4 倍——再加上主持人們在該平臺上親手打造個人軟體的經驗。讀者讀完應該能具體掌握：一家開發者基礎設施公司如何為代理重新整備自己、Postgres 擴充套件的極限在哪裡，以及為什麼主持人認為當前的時勢有利於小型、有獲利的軟體事業，而非創投規模的垂直 SaaS。

Supabase 2026 年成長急遽轉折，動能來自非工程師 builder

Copplestone 表示，過去一年出現了他形容為「巨大轉變」的轉折點。註冊數從約 300 萬成長到 1,300 萬，代管資料庫從約 800 萬成長到逼近 5,000 萬。他說，今年營收將成長 4 倍，平臺現在每週新增約一百萬座資料庫。

Copplestone 指出，不尋常之處在於漏斗頂端與下游指標同步移動。通常註冊數加速成長會拖累啟用率與轉換率；但今年他說，「它們全部都在往右上走」。他把這歸因於模型變強，以及一種新的客戶輪廓：過去沒有軟體工程背景、如今也能動手打造產品的人。軟體工程師仍佔使用者的一大部分，但 builder 這塊成長最快。

Copplestone 說，早期投資人曾警告，產品驅動成長（product-led growth）終會撞上營收天花板，逼公司往上游市場走。「到目前為止，看起來根本沒有天花板，」他說。「我也看不出它會在哪裡停下來。」

客戶正從開發者轉向具領域專業的 builder

主持人與 Copplestone 對 builder 的定義逐漸收斂：builder 是知道自己該做什麼、但以前做不出來的人。Taggar 舉了一位金融科技創辦人為例——公司市值超過十億美元，數學系出身，會寫一點 Ruby，但一直得靠工程師——如今他自行打造個人理財軟體，連銀行串接都從零寫起。Copplestone 的例子則是一位約 50 歲的巴西計程車司機，完全用手機做出一個在地市場的叫車 App，還到 Supabase 的研討會上「滿懷感激」地表達謝意。

Copplestone 主張這個族群之所以重要：領域專家最清楚自己利基裡尚未解決的問題，而且不再需要說服工程師加入。他把 Supabase 定位為「索引公司」——一開始的目標是拿下每一家 YC 公司，讓自己在企業生命的第一天就在場；使命沒變，變的只是視野的廣度。「如今隨著更多 builder 上線，我們知道自己必須服務他們，而這其實是完全不同的問題。」

Friedman 點出這當中的歷史反差：資料庫以往是少數幾套由大企業維運的超大型系統，而「直接面向消費者的資料庫生意」這種點子「聽起來就像語法錯誤」。如今 Supabase 兩端都有——一端是早期新創，採類似 Stripe 的先進場再擴張模式；另一端是個人，其個人資料會隨一生累積。Copplestone 稱這塊專業消費者（prosumer）市場是「很好的成長向量」。

個人資料庫正成為代理的紀錄來源

Mirchandani 在節目錄製前約半年「迷上 OpenClaw」之後，在 Supabase 上打造了一套他稱為「Control Tower」的個人系統。他原本預測未來不會有 UI、一切都在 Markdown 裡，後來卻發現自己資料庫和 UI 兩者都需要。這套系統會分流電子郵件、追蹤財務、體重與健身紀錄，並接收由代理分類的檔案上傳。他主張，自己的個人理財區塊至少已與 Mint 或 Monarch 功能相當，某些方面甚至更好，因為它能透過在自己的 G-Brain 裡查詢交易對手方來釐清一筆交易，再正確分類——這在過去足以支撐好幾家新創。

Taggar 的健康案例說明瞭跨來源情境的價值：由於資料庫同時有行事曆存取權，代理可以把最近體重增加解釋為出差所致，並提醒他下週回到正軌。Copplestone 說，財務與健康是他最常看到的兩大個人用途，而把各種裝置同步進單一資料庫是「一種魔法般的技能」，因為這讓關聯分析得以成立。

Copplestone 補上一點提醒：當他把愈來愈多日常流程與 CRM 都放進同一個代理後，他開始對被綁死「有點偏執」，於是動手把資料抽出來，讓任何代理都能接上。Taggar 的結論是：有價值的是資料庫，不是 App——掌握紀錄來源，把代理疊在上面，而不是把一切留在別人的資料庫裡。

「一年前我根本不會想到自己會想要一座個人資料庫，因為那時完全沒道理。但現在，它其實是最有價值的東西。」——Harj Taggar

Supabase 三度改組，跟著 builder 的實際所在走

Copplestone 把歷程分成三章。第一章是儀錶板公司：創立時的洞察是，連軟體工程師都搞不定資料庫，於是團隊打造了「一個長得像 Airtable、架在 Postgres 上的 UI」。第二章是 API 公司：2021 年前後有客戶表示想用程式化方式大量開資料庫、需要 API，這個轉向在 2024 年開花結果，Bolt、Lovable 等工具都建在 Supabase 上。第三章是程式碼優先公司：Copplestone 注意到已經沒人拜訪儀錶板，於是發布內部產品備忘錄，要求儀錶板上能做的事都必須也能用程式碼完成，並把 CLI 與工具鏈重新架構到能在沙箱中執行。

他舉 Parse 與 Firebase 為前例，說它們「開闢了道路」，證明獨立資料庫公司可以名正言順地存在——在那之前，不用 RDS 簡直荒謬。他也歸功於時機：MongoDB 推動 NoSQL 與行動浪潮創造了先前的機會，而 Supabase 也搭上了同等級的浪潮。

要擴充套件到每月十億座資料庫，需要兩套架構而非一套

Copplestone 算了一下天花板：如果 ChatGPT 約 12 億週活躍使用者每人每月都開一個東西，那就是每月 12 億座資料庫——一個「資料庫領域從來不必面對」的規模。他的答案是兩款定位相反的產品。

flowchart TD
    A["Builder 啟動專案"] --> B["Supabase Spark（Torso 架構）"]
    B -->|"原型階段工作負載，相容 SQLite"| C["相同體驗、相同工具鏈"]
    C -->|"業務成長"| D["Multigres（Postgres，可擴充套件至 PB 級）"]
    D --> E["企業級規模"]
    B -.->|"標語：從原型到 PB 級"| D

Supabase 近期收購了 Torso，其架構同時相容 Postgres 與 SQLite，將用來支撐一個名為 Supabase Spark 的方案，服務入門階段的工作負載。Multigres 則負責擴充套件到 PB 級。Copplestone 坦承這套雙軌策略「極其困難」，尤其在目前的成長速度與人力擴編之下，但他說「很好玩」。他也提到一項現實限制：「現在大家都在搶算力」，所以想靠跟 AWS 談到更好的條件並不是捷徑。

Taggar 點出策略張力：AI 之前的傳統智慧認為，資料庫公司必須像 Oracle 那樣快速打進企業市場，因為錢在那裡。Copplestone 的回應是 Supabase 兩端都要。他引用一個自己記不太清楚、還請大家幫忙查證的統計——AWS 營收中約有 40% 來自那些從 AWS 起家、後來規模化的新創——並說那正是 Supabase 想拿下的類別，因為遷移資料庫供應商「幾乎不可能」。Taggar 把這個模式比作 Stripe：第一天就拿下客戶，然後跟著成長最快的公司一起長大一整個世代。

Supabase 內部代理採用率六個月內從 10% 躍升至 60% 工程師

Copplestone 說 Supabase 沒有內部 AI 政策，工程師想要什麼工具就給什麼工具。一次內部調查顯示，用編碼代理寫出 80% 程式碼的工程師佔比，在約六個月內從 10% 升到 60%。他強調產出不是隨便的 vibe-coding，而是「相當高強度」的內部工作，而且這個轉變已把很大一部分工程心力推向測試與測試工具鏈，用來驗證結果。

Mirchandani 指出 YC 公司普遍出現同樣的模式——Blacksmith、Depot、UbiCloud——全都在賣 CI 與測試基礎設施，因為測試量暴增。Copplestone 說工程師一開始需要被說服，而模型進步加上公開展示能力（他提到「那些 Navier-Stokes 的東西」）完成了說服工作。

產品上的意涵是：代理現在是主要使用者。Copplestone 說他自己是對著手機上的代理講話來開發，刻意從不讀程式碼，藉此模擬一年後非工程師會怎麼使用 Supabase。他描述某個深夜為 openusd.dev 這個網域建開發者網站的過程：他要求調整資訊架構，代理約 20 秒就實作完成，成果文筆流暢、內部連結完整、SEO 也設定好了。「那真的像是我瞥見未來的那種時刻之一。」

贏得代理，靠的是成為預設選項，然後絕不讓它卡住

Copplestone 把代理採用拆成兩階段：被模型選中，以及在代理撞牆時能撐過去。第一階段，他認為開源「至關重要」，儘管他坦承反事實無從得知。Supabase 支援整個 Postgres 生態系，而不只是自家工具，這讓它散佈在許多社群之中。他預期隨著企業採用供應商前堅持檢查原始碼以確保安全，開源的重要性會更高。

第二階段，Supabase 重寫了錯誤訊息，讓它們告訴代理如何修正問題、或該讀哪份檔案，而不是隻回一個光禿禿的 500。「你確實得把很多原本只為人類和開發者設計的東西，為代理重新設計一遍，」他說。公司內部有一套評估套件，也有一個公開的 evals 網站，比較不同模型在 Supabase 與 Postgres 上的建構表現；如今很大一部分工程心力花在測試特定使用情境，而不是打造功能。

Friedman 提議辦一場給代理參加的研討會——派代理去 Supabase Select 聽發表、順便整合新功能——Copplestone 說這「太狂了」，值得一做。

G-Brain 顯示真正的瓶頸是檢索，而非原始上下文

Mirchandani 介紹 G-Brain——他為 OpenClaw 打造的開源檢索層——說它是先前在 Rails 上打造代理式新聞編輯室經驗的濃縮版，那時每一次 LLM 呼叫都被視為昂貴又危險。OpenClaw 把這件事反了過來：給代理資料與能力，讓它自己去做。他指出一百萬個 Token 是很大的工作記憶——大約三本《哈利波特》——但任何時刻要挑對那三本書，本質上是檢索問題。面對五十萬個 Markdown 檔、30–40 GB 的語料，他需要 pgvector 與 Postgres；而在 SQL 裡做圖結構很輕鬆。

G-Brain 結合 RAG 檢索與圖資料庫，透過動態 schema 替非結構化資料加上結構，他把它比作早期的 Palantir。代理查詢後會拿回一份報告，載入上下文。Supabase 以自動擴充套件處理 50–300 GB 的語料，他說 OpenClaw 現在已能進入 Supabase 自行管理資料庫。

他的評估迴圈值得一提：他把生產環境使用的追蹤紀錄抽到另一個 gbrain-eval repo，約有 40 個類別，涵蓋檢索品質、成本效率與延遲。一個代理在自動研究迴圈中反覆嘗試，凡是能提升分數的改動預設就合併到 master；失敗的實驗則寫成 Markdown 存檔。另有一個常駐代理專門發想新的評估類別。他稱這是「針對特定使用情境、非常非常原始版的 RSI（遞迴自我改進）」。

Copplestone 轉述一場關於資料庫未來的晚餐上的想法：讓代理進入迴圈，為特定查詢模式設計最佳索引或資料結構，把 10 秒的搜尋變成不到一秒。Mirchandani 同意，一旦程式碼生成夠強，動態檢索勢在必行。

小型、有獲利的軟體公司可能勝過創投規模的垂直 SaaS

Mirchandani 指出，垂直 SaaS 創辦人現在要在 500–1,000 萬美元 ARR 的水準募 A 輪相當吃力，而這樣的水準在 9–12 個月前幾乎是保證過關；相較之下，橫向與 AI 相關投資仍一路放行。與此同時，創辦人可以用 10–15 人做到 1,000–1,500 萬美元，有時甚至 2,500–5,000 萬美元營收。Copplestone 算了一下：15 人、200 萬美元 ARR、50% 毛利率，等於每人每年約一百萬美元——「對很多人來說是超棒的結果」。

Mirchandani 說，現在很多 office hours 的對話，都是創辦人達到某個里程碑、卻因為募不到資而失望，但更合理的解讀是：他們已經不需要這筆錢了。Copplestone 同意募資這個「徽章」被高估了：「現在真的不去募資，在我看來反而像是，喔，那才是達成了了不起的事。所以我有點羨慕那些走到這一步的公司。」

Copplestone 眼中能在反覆平臺轉移中存續的公司特質

Copplestone 的第一原則是類別耐久性——林迪效應（Lindy effect）。資料庫已存在 50 年，他說再過 50 年也還會在，所以無論 AI 帶來什麼，「資料庫一定還在」。第二是適應力：Supabase 不試圖什麼都有答案，而是試圖適應得最快。他批評一些開發者工具從開發者導向起家、往上游走、變得企業化，然後停滯；他舉 Stripe 為例，說其創辦人始終把注意力放在新的建構方式上。

戰術上，他建議 dogfooding（「沒有比你自己卡在自家工具上更好的回饋」）、與關鍵生態系夥伴合作以提早得知他們在做什麼，並刻意在團隊裡留出餘裕，好讓新點子有機會嘗試。他說多數押注即使看起來很有希望也會失敗，但成功的那些能讓公司乘浪而起。

「我確實認為，世界上每個能用 AI 的人，某種程度上都會變成 builder。」——Paul Copplestone

綜合這些線索，Supabase 押的與其說是任何單一產品，不如說是在專案啟動的那一刻成為預設的紀錄來源——無論那個專案是 YC 新創，還是計程車司機的在地 App。這個押注也帶來本集未解的結構性張力：要有利可圖地服務十億座微型資料庫，需要更便宜的架構（Torso／Supabase Spark）；要服務存活下來的客戶，又需要 PB 級 Postgres（Multigres）；而 Copplestone 坦承在這樣的成長速度下同時跑兩套「極其困難」。另一個未解問題是：builder 經濟究竟會產出可長可久的事業，還是大多隻是個人軟體；Copplestone 對 2027 年的樂觀建立在前者，而主持人目前舉的例子大多屬於後者。值得持續追蹤的是：面向代理的錯誤訊息與評估套件是否會成為開發者基礎設施的標準層，以及垂直 SaaS 的募資緊縮是否會把更多創辦人推向 Copplestone 說他羨慕的那種小型、有獲利模式。