企業數據庫幾乎不會遷移：新客戶才是真正能贏的戰場
Supabase 內部數據顯示企業幾乎不會把生產數據庫搬家，這決定了他們的增長策略是搶佔綠地新項目，而不是攻克巨頭的存量客戶。
原視頻在 YouTube 上放不出來，用音頻聽：
核心論點 · 點時間戳可跳到原聲
聲明式schema是Postgres欠的最後一課
Supabase 把declarative schema(聲明式模式)當作build主題裡最重要的一步——傳統Postgres走的是「建schema、然後不斷migrate」的路徑，而agent需要的是一份放在Git裡、隨時可讀的「數據庫此刻長什麼樣」的文件。節目裡說這事看似簡單，但Postgres設計於40年前，從來沒為此優化過，Supabase現在做的正是把這塊「最後一公里」的適配補齊，而且這個能力不只是agent用得上，人也一樣受益。
— swyx所有Postgres運維工具都會丟數據
Supabase測過Postgres生態裡幾乎所有operator(負責管理集群、故障轉移、備份的運維層),發現在特定條件下每一個都會丟數據。於是他們決定把operator這層從頭重寫，這就是Multigress——不是先做分片(sharding),而是先做到和原生Postgres完全兼容，查詢一行都不用改。目前已經做過1000次連續故障轉移測試，零數據丟失，明年初有望落地分片功能。
從每月500萬到數十億個數據庫
Supabase現在每月要在平臺上啟動大約500萬個數據庫，但創始人判斷未來必須支撐到每月數十億個——這是完全不同量級的問題。為此他們收購了Turso,看中的不是它的SQLite技術本身，而是它圍繞對象存儲重新設計的架構：靠對象存儲11個9的持久性做底座，再把SQLite當文件格式用，這樣才launch得起數十億個小型數據庫。
一筆訂單讓他們確信vibe coding是真的
早期他們對vibe coding這波浪潮將信將疑，直到看到有人在產品上線後幾天內就靠Stripe賺到了一萬美元——這才讓團隊確認這不是玩具，而是會留下來的東西，於是決定兩頭都做：既服務剛起步的原型，也同時投入資源支撐客戶規模做大之後的需求，這也是後來「build in a weekend, scale to millions」升級為「prototype to petabyte」的由來。
銷售提成只看比對照組多出來的增長
Supabase的銷售不是傳統的打電話推銷，而是先用AI從上千個產品觸發信號(比如客戶快碰到用量上限、報錯變多)裡篩出一批，只給其中回覆了的人派銷售跟進，把沒回復的人當對照組。對照組本身也會自然增長25%,而銷售跟進過的客戶增長125%,銷售只按這多出來的100%增量拿提成——這套機制讓團隊知道銷售真正創造了多少價值，而不是把客戶本來就會有的增長也算成業績。
企業客戶幾乎不會遷移數據庫
創始人直言，哪怕做出更大更能擴展的Postgres,也幾乎不可能說服企業把生產數據庫搬過來——這是他們研究過的所有數據庫公司都驗證過的教訓。所以企業側的全部精力放在落地第一天而非搶存量：贏下新項目的greenfield場景，而不是指望Oracle之類的巨頭客戶整體遷移過來，這個判斷會決定未來至少五年的打法。
把Postgres變成一份agent能讀的文件
過去Postgres靠一連串migration文件記錄數據庫變化，想知道某張表現在長什麼樣，agent得翻完上千個文件、或者把數據庫跑起來再內省，速度太慢。Supabase這次發布的pgdelta,把表、policy、註釋等等全部變成declarative schema文件夾裡的一份「當前狀態」快照，agent只要讀文件就知道數據庫此刻的真實形狀，不用recompile也不用一級級migrate。
token花費超人力工資1.5倍就是警訊
創始人給出一個可以帶走的基準：把公司每月AI花費除以人力工資總額，算出一個比值。大多數公司這個比值大概在0.1左右；升到1附近還算安全；一旦超過1.5,大概率是在浪費錢，而不是真的省了人力。Supabase自己目前每月AI花費約30萬美元、團隊450人，他們更關心的不是省了多少錢，而是有多少原本需要人盯的流程被徹底自動化掉了。
原話 · 已逐字校驗
what we had found was that under, um, certain conditions, every single one of them could lose data.
我們發現，在某些條件下，所有(Postgres運維工具)無一例外都會丟數據。
So then they built this Turso architecture, which basically builds MVCC for SQLite so that you can have multiple writers.
於是他們搭建了Turso這套架構，本質上是給SQLite做了MVCC,讓你可以有多個寫入者。
it turns out just getting on a call and helping people out, their account then grows a hundred and twenty-five percent. So that a hundred percent uplift, the incremental uplift, is what we compensate our salespeople.
結果發現，僅僅是打個電話幫客戶解決問題，對方賬戶就能增長125%。所以我們給銷售的提成，就是這多出來的100%增量。
I guarantee they'll almost never migrate.
我敢保證，他們幾乎永遠不會遷移。
I think it was like one year ago, someone said that only five percent of Oracle workloads by revenue ran in the cloud.
大概一年前，有人說按收入計算，Oracle的工作負載只有5%是跑在雲上的。
there's, like, layers upon which you want to get to where things will be rewritten, and then you don't wanna be spending your actual innovation tokens or your actual tokens rewriting everything.
總會有些層級的東西最終值得重寫，但你不會想把創新的token、真正的token都耗在重寫所有東西上。
you can probably go up to one pretty safely, and if you're over 1.5, you're probably in trouble.
這個比值大概升到1還算安全，要是超過1.5,你可能就有麻煩了。
數字與實體
| OrioleDB 性能提升 | 比現有Postgres存儲引擎快1.5-2倍 | 7:26 |
| Multigress 容錯測試 | 1000次連續故障轉移，零數據丟失 | 9:27 |
| 當前每月新建數據庫數 | 約500萬個 | 12:44 |
| ChatGPT 月活用戶 | 12億 | 55:58 |
| Oracle 雲上工作負載佔比(按收入，約一年前) | 5% | 48:19 |
| Supabase 每月AI花費 | 約30萬美元，團隊450人 | 1:12:16 |
| 健康的token花費/人力工資比值 | 常見約0.1,超過1.5視為危險信號 | 1:12:16 |
術語
- AEO回答引擎優化
- 讓AI大模型在回答用戶問題時把自己推薦出來的優化方法
- VitessVitess
- YouTube、GitHub在用的MySQL分片中間件，Multigress是其Postgres版對標
- MultigressMultigress
- Supabase為Postgres重寫的集群/分片操作系統
- declarative schema聲明式模式
- 用文件直接描述數據庫當前結構，而非靠一連串migration腳本推導
- MVCC多版本併發控制
- 允許多個寫入者同時操作同一份數據而不互相阻塞的機制
收聽指南
關注AI原生後端基建、企業數據庫遷移策略、以及如何給團隊AI花費定基準的創業者、投資人和工程師。
開頭0:00-5:20是主持人個人開場白和節目通知，內容後面正式訪談會重新講到，可直接跳過。