# 氛圍編程時代中小企業打造 SaaS 的 DB 最優解 — Cloudflare D1 × 單租戶擊碎 DB 成本壁壘

> AI(氛圍編程)讓『構建』的成本歸零。本文聚焦在大規模運營眾多服務時,DB 究竟該如何選擇。

Date: 2026-05-13

Tags: Cloudflare, D1, SaaS, 架構, AI, 中小企業

---

![基於 Cloudflare D1 的單租戶 SaaS 架構](https://img.wiredxeco.com/wiredxeco/cloudflare-d1-single-tenant/hero.webp)

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 的遷移設計,還是量產期的遷移運營設計,歡迎隨時聯繫我們。