BLOG
氛圍編程時代中小企業打造 SaaS 的 DB 最優解 — Cloudflare D1 × 單租戶擊碎 DB 成本壁壘
AI(氛圍編程)讓『構建』的成本歸零。本文聚焦在大規模運營眾多服務時,DB 究竟該如何選擇。
AI 讓「構建功能」的成本幾乎歸零。哪怕是小團隊,也能以與大廠相同的速度推出與大廠相同的功能。然而,服務一上線就會立刻撞上「基礎設施固定費」這堵牆 — 尤其是以 AWS RDS 為代表的獨佔型數據庫的維持成本。
用 Cloudflare D1 加上「一個客戶一個 DB」的單租戶策略,正面把這堵牆擊碎。我認為這正是當下中小企業運營大規模 SaaS 的最短路徑。
「全員塞進一個 DB」的時代已經結束
迄今為止大規模 SaaS 選擇多租戶(把所有客戶拼車在一個巨大 RDB 上)的理由,幾乎只有一個。RDS 和 Aurora 的固定費太貴,只有拼車才能算得過賬。
但拼車始終要付出代價。
- 安全事故的溫床: 一個
WHERE tenant_id = ?忘了寫,其他公司的數據就會混入響應。無論評審多麼嚴格,都不可能把這個風險降到零。 - 吵鬧鄰居問題: 一旦某個巨型客戶的查詢把 DB 堵住,毫不相干的其他公司也跟著一起慢下來。
- 難以利用 AI: 想給 RAG 喂「只有這個客戶的數據」時,要從所有客戶混在一起的 DB 裡安全地把數據抽出來,其邏輯比想象中要重得多。提示注入觸達其他公司數據的事故也已經在現實中發生過。
我認為這種結構,在 AI 能造一切的時代,不應該原封不動地繼續沿用。
Cloudflare D1 改變基礎設施的前提
D1 是基於 SQLite、分佈部署在 Cloudflare 邊緣的無服務器關係型 DB。對於量產 SaaS 的一方來說,有什麼不同?
- 固定費幾乎為零: 閒置的 DB 不必付錢。即使「以防萬一」立了 100 個 DB 一直掛著,只要它們是空的,就不會被收費。
- 可以動態生成 DB: 每次籤新合同,只需一個 API 就能成立「為這位客戶建一個專屬 D1」。要在 RDS 上做同樣的事,先被罵的是財務。
- 與 Workers 無縫銜接: 從 Worker 訪問在網絡上幾乎是零跳。多區域讀取也是標配。
那些過去「太奢侈而做不到」的單租戶架構,在 D1 裡變成默認選項。
單租戶(一個客戶一個 DB)的壓倒性優勢
中小企業與大廠正面交鋒時,這種架構本身就能直接拿來當銷售話術。
可以說「在物理上是隔離的」
B2B SaaS 商談中,信息系統部門或法務最先問的就是「跟其他公司的數據是否分開」。多租戶只能回答「在邏輯上是分離的」,而單租戶則可以立刻回答「DB 文件本身就是兩份」。這直接影響合同的簽訂速度。
AI / RAG 變得無比簡單
DB 按客戶劃分後,允許 AI 參照的範圍從一開始就在物理上被固定。
- 一句「只讀這位客戶的 DB」就夠了。
- 越界訪問其他公司數據在結構上不可能。
- 檢索精度也會提升 — 因為噪聲變少了。
與其在多租戶中拼命做 RAG 的權限分離,先把 DB 拆開,反而是結果上更快的做法。
數據的可攜性
被客戶說「我要解約,把數據還給我」時,遞過去一個 SQLite 文件就完事了。不用每次現寫導出批處理。解約體驗好的 SaaS 續約率也高,這是我個人的觀察。
缺點,以及越過它的「覺悟」
當然不是銀彈。單租戶量產有其特有的難處。
遷移自動化是必須的
「同時給 1,000 個 DB 加一列」這種操作會變成日常。手工操作從一開始就不可能 — 必須自建遷移執行器,且要把失敗時的回滾和重試也成套搭好。這部分就算讓 AI 來寫,也必須由人類做最終評審。
跨客戶分析需要另一條管道
被要求「給我所有客戶的月活」時,逐個對 1,000 個 D1 發 SQL 跑一圈並不現實。
- 把每個 D1 的數據 ETL 進分析用 DB(DuckDB、BigQuery、ClickHouse 等)。
- 聚合在那一側進行。
簡而言之,就是從一開始就把 OLTP 和 OLAP 分開的設計。在多租戶裡很容易屈服於「同一個 DB 同時幹這兩件事」的誘惑,而單租戶會強制把你趕進正確的結構裡。
巨型客戶的「畢業方案」
即使在單租戶時代,某一個 DB 也可能撞上容量或 QPS 的上限。要從一開始就準備好這樣的設計: 只把那一位客戶切到另一套基礎設施(專用 D1,或另一種配置的 RDS 等)上。具體做法是: 永遠夾一層用於把租戶 ID 解析為「該連哪個 DB」的層。
誰掌握基礎設施,誰就掌握 AI 時代的 SaaS
在「構建」的成本歸零的世界裡,決定勝負的是**「能否以最低成本、安全地、可擴展地持續運營」**。
被沉重笨大的 RDS 固定費拴著,再往上堆 AI 功能,收益結構也不會變健康。用 Cloudflare D1 量產 DB,把按客戶優化過的價值連同單租戶的安心感一起送達。我認為這一組合,是中小企業自稱大規模 SaaS 運營商的最現實裝備。
株式會社 Wired & Eco 接受以這套架構為前提的 SaaS 開發、遷移諮詢。無論是現有多租戶 SaaS 的單租戶化探討、向 D1 的遷移設計,還是量產期的遷移運營設計,歡迎隨時聯繫我們。