Cloudflare D1 是什么
一句话总结
Cloudflare D1 是基于 SQLite 的边缘原生关系型数据库，Workers 通过内置绑定直接调用，无需管理连接池和服务器。
🤔 为什么会有它 / 解决了什么问题
传统关系型数据库（PostgreSQL、MySQL）在边缘计算环境下有两大痛点：连接数爆炸（几千个 Worker 同时建连）、延迟波动大（数据库不在边缘）。D1 把 SQLite 搬到边缘，每个读请求在本地节点完成。
🔍 具体原理 / 运作逻辑
D1 基于 Durable Objects 构建，核心数据库通过 SQLite 引擎运行在 CF 的全球分布式存储上。读请求在最近的边缘节点缓存执行，写请求通过分布式共识复制到多个节点。
更硬核的技术细节（点击展开）
每个 D1 数据库是一个 SQLite 文件，底层存储在 Durable Objects 的存储层。数据库大小上限 10GB（当前 GA 限制），并发写事务通过单一协调者序列化。支持 WAL 模式，但不支持外键约束。
🧭 什么情况下会用到 / 什么场景会遇到它
- Cloud Vibe SDK 的默认数据层（原型快速验证）
- Cloud Mail 的用户配置和邮件索引存储
- 轻量级 CRUD 应用，不需要复杂 JOIN 或全文索引
🛠️ 怎么上手 / 在哪操作
登录 Cloudflare Dashboard → D1 → 创建数据库，然后用 wrangler d1 execute 执行 SQL 或绑定到 Workers 通过 env.DB 调用。
⚖️ 副作用 / 代价 / 取舍
- 单库最大 10GB（不适合海量数据）
- SQLite 级联限制：不支持 ALTER COLUMN、外键约束、行级安全
- 写入吞吐有限（单协调者序列化），高并发写入场景不是对手
- 目前仅 CF 内部托管，不能自托管或导出完整 SQLite 文件
🕰️ 来历
- 谁提出/创造的：Cloudflare（基于 SQLite + Durable Objects）
- 什么时候出现的：2022 年 5 月公开 Beta，2024 年 4 月正式 GA（生日周宣布）
🔗 关联 / 经常一起出现的概念
- Cloudflare Workers：D1 的”天然伴侣”，通过 Workers Binding 零配置调用
- Cloudflare Hyperdrive：连接传统 Postgres/MySQL 到 Workers，D1 替代方案（不改数据库模式）
- SQLite：D1 的底层引擎，意味着 D1 继承了 SQLite 的全部能力与限制
⚠️ 注意事项 / 常见误区
“D1 是边缘版 Postgres”——不是。它是 SQLite，没有存储过程、触发器、自定义类型、外键约束。如果应用需要强关系模型约束，D1 不适合；建议走 Hyperdrive + Postgres 组合。
📎 记忆锚点
“每个 D1 数据库就是一个 SQLite 文件，放到了全球边缘。”
📝 更新日志
| 日期 | 改动 | 原因 |
|---|---|---|
| 2026-07-13 | 首次创建 | - |