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 的迁移设计,还是量产期的迁移运营设计,欢迎随时联系我们。