# 氛围编程时代中小企业打造 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 的迁移设计,还是量产期的迁移运营设计,欢迎随时联系我们。