D1 vs Supabase、Neon：边缘 SQLite 与 Serverless Postgres 怎么选
从运行模型、SQL 能力、容量、一致性、平台服务与计费维度比较 Cloudflare D1、Supabase 和 Neon。
编辑与核验：橙宝书编辑团队 ·
它们不是同一层产品
D1 是与 Workers Binding 紧密结合的 serverless SQLite 数据库；Supabase 是围绕完整 PostgreSQL 提供 Auth、Storage、Realtime、API 等能力的 BaaS；Neon 是计算与存储分离、支持伸缩和数据库分支的 serverless Postgres。先选应用抽象层，再比较额度，才是公平选型。
三种运行模型
详细说明
- 01D1
应用面向 Binding 和 SQLite，省去连接池，但接受单库与写入模型边界。
- 02Supabase
数据库只是平台中心，还可以直接采用 Auth、Storage、Realtime 与自动 API。
- 03Neon
应用保留标准 Postgres 接口，按需获得伸缩、闲置归零与数据库分支。
| 维度 | Cloudflare D1 | Supabase | Neon |
|---|---|---|---|
| 数据库内核 | SQLite 语义，Cloudflare 托管 | 完整 PostgreSQL | 完整 PostgreSQL，计算与存储分离 |
| 应用接口 | Workers Binding、Sessions API、HTTP API/工具链 | JS 等 SDK、自动 REST/GraphQL 能力、标准连接串 | 标准 Postgres 连接串、serverless driver 与常见 ORM |
| 平台范围 | 数据库本身，与 Workers、Queues、R2 等组合 | 数据库 + Auth + Storage + Realtime + Functions 等 BaaS | 以 serverless Postgres、分支、伸缩与开发工作流为核心 |
| 伸缩方式 | 单库查询串行执行；可按租户拆成很多数据库 | 每项目专属计算，按方案与实例资源伸缩 | 计算自动伸缩、可闲置归零，存储独立增长 |
| 全球读取 | Read Replication 需 Sessions API；写入仍到主库 | 依据项目区域与平台提供的只读副本能力 | 依据区域与只读副本/计算配置 |
| 容量边界 | Paid 单数据库硬上限 10 GB；适合拆库/多租户 | 由项目计算、磁盘与方案决定，可承载更大的单一 Postgres | 由计算、存储和方案决定，可承载更大的单一 Postgres |
| 强项 | Workers 原生、无连接池、按行与存储计费、可拆租户 | 一体化后端、RLS、扩展、实时、认证和存储 | 标准 Postgres 兼容、分支、预览环境、弹性计算 |
| 主要代价 | SQLite/Postgres 差异、单库上限、串行写入热点 | 平台面更大，项目计算、磁盘、出网和功能共同影响账单 | 仍需正确处理连接、区域、冷启动与 CU-hour 使用 |
D1 的限制决定数据模型
根据 D1 Limits，Free 单库上限为 500 MB，Paid 单库硬上限为 10 GB；单个数据库在同一时刻按顺序执行查询。它非常适合把租户、站点、工作区或项目拆成独立数据库，却不适合把一个不断增长的分析仓库硬塞进单库。
D1 Read Replication 会在全球建立只读副本，但应用需要使用 Sessions API 和 bookmark 保持 sequential consistency。写入仍回到主库，它不是多主数据库，也不会消除热门单行或单库写入竞争。
SQL 方面，D1 遵循 SQLite 约定并支持文档列出的扩展；迁移已有 Postgres 应用前，应逐项检查类型、扩展、函数、并发事务和 ORM 生成 SQL，而不是只验证简单 SELECT。
计费不能横向抄一个数字
| 平台 | 计费形状 | 当前免费/包含量的理解方式 |
|---|---|---|
| D1 | rows read、rows written、存储；不用为 D1 出网付费，Worker 本身另计 | Free 每日 500 万行读取、10 万行写入，总存储 5 GB；Paid 月度含 250 亿行读取、5000 万行写入、5 GB，再按超额行数与容量计费 |
| Supabase | 组织方案 + 每项目专属计算，再叠加磁盘、出网与功能用量 | 这是完整后端平台账单，不能只拿数据库容量与 D1 比；以 Supabase Billing 的当前组织和项目口径计算 |
| Neon | CU-hour 计算 + 存储 + 历史/额外能力 | Free、Launch、Scale 的计算与存储包含量不同；以 Neon Pricing 和真实 active/idle 曲线复算 |
截至核验日，D1 Paid 超额读取为 0.001 美元/百万行、写入为 1 美元/百万行、存储为 0.75 美元/GB-month；Neon 公开页列出的 Launch 计算为 0.106 美元/CU-hour、存储为 0.35 美元/GB-month。两者单位完全不同：一个按扫描/写入的行，一个按 Postgres 计算时间与存储，不能用单价大小直接宣布胜负。
行读取不是 API 请求
一次没有合适索引的查询可能扫描很多行；给 D1 估算时必须记录 rows_read，而不是只数 HTTP 请求。反过来，Postgres 平台的连接、计算时长、实例大小、磁盘和出网也不能被折算成“每请求多少钱”的假精度。
按应用选择，而不是按流行度选择
D1 更适合
- Workers 原生的 SaaS、CMS 或轻量 API，每个租户/站点数据可独立拆库。
- 关系数据量有限，希望通过 Binding 避免连接池与公开数据库凭证。
- 读多写少，查询可建立明确索引，并能接受写入集中到主库。
- 想把 D1 元数据与 R2 文件、Queues 异步任务、Durable Objects 协调组合。
Supabase 更适合
- 团队需要数据库之外的 Auth、Storage、Realtime、RLS 和自动 API，且愿意采用一体化平台。
- 应用依赖 PostgreSQL 扩展、复杂 SQL、触发器或数据库级权限模型。
- AI 生成了完整 SaaS/CMS 前端，需要尽快补上成熟认证和后端能力，但团队仍会审查 RLS 与密钥边界。
Neon 更适合
- 必须保持标准 PostgreSQL、ORM 与驱动兼容，同时希望计算闲置归零或自动伸缩。
- 每个 PR/预览环境需要数据库分支，或者开发测试数据流是核心效率瓶颈。
- 数据库是主要产品边界，不需要同时购买一个完整 BaaS 抽象。
详细说明
给 AI 的约束比“帮我选数据库”更重要
先了解 Cloudflare 内部存储分工可读KV、D1、R2 与 Durable Objects 选型；选定 D1 后进入迁移、本地验证与 Time Travel 发布手册。可运行例子包括 Workers + D1 API、多租户 SaaS和内容 CMS。
官方与厂商来源
这篇内容帮你完成目标了吗？
内测反馈只在当前浏览器生成，不会自动上传。