比较 D1、PlanetScale 和 Neon 的基准往往会测量错误的东西。以微秒为单位的延迟、每秒查询的吞吐量、综合查询的结果 - 这些数字都没有回答重要的问题：这三个银行中的哪一个适合您现在正在构建的内容，考虑您的数据将在哪里增长，在没有流量时您想要支付多少费用，以及您的代码采用哪种 SQL 方言。三种不同的架构具有不同的权衡，而不是同一产品的性能变化。
D1：SQLite 处于边缘，零入门成本
D1 的核心论点是与 [Cloudflare Workers4 的本机集成。当Worker通过绑定访问D1数据库时，没有TCP握手，没有连接字符串，没有连接池需要管理。查询直接进入同一运行时上下文中的 D1 绑定，建立调用的延迟为亚毫秒级。在每一毫秒的开销都很重要的无服务器架构中，这种集成是真实且可衡量的。
免费套餐提供 5GB 存储空间，每天读取 500 万行，每天写入 10 万行，足以用于实际流量较低的开发、内部工具和原型。付费计划：每百万行读取 0.001 美元，每百万行写入 1 美元，存储每月 0.75 美元/GB。通过0进行本地开发会在计算机上创建一个真实的 SQLite 文件，其行为与远程数据库相同。
定义 D1 无效的限制：每个银行 2GB、付费计划中有 10 个银行、除了用于向量搜索的 sqlite-vec 之外没有自定义 SQLite 扩展。增长超过 2GB 的 Bank 在 D1 内没有扩展路径 - 您需要在达到限制之前拆分数据或迁移到另一个 Bank。对于预计将超过此上限的应用程序，D1 是开始时的正确银行，但长期持有的银行则是错误的。
PlanetScale：具有水平分片和模式分支的 MySQL
PlanetScale 构建于 Vitess 之上，该基础设施与将 YouTube 的 MySQL 扩展到标准 MySQL 无法处理的容量的数据库 5 基础设施相同。这个起源定义了 PlanetScale 提供的内容：真正的 MySQL（大多数 ORM 无需修改即可工作）、随着数据增长而进行的平台管理水平分片，以及将 PlanetScale 与当今任何其他可用数据库区分开来的模式分支工作流程。
模式分支的工作方式类似于模式的版本控制：创建模式分支、应用更改、测试并合并回主分支。迁移运行时无需锁定表，这与 MySQL 的标准 ALTER TABLE 不同，后者会在执行期间锁定写入。对于那些在迁移维护窗口中苦苦挣扎或需要安全地恢复架构更改的团队来说，此功能解决了一个真正的问题。
成本是最重要的过滤器：PlanetScale 于 2024 年结束了免费套餐。Scaler 计划起价为 39 美元/月。对于副业项目和非收入早期应用程序，该楼层不再选择 PlanetScale。对于收入稳定的产品和拥有 MySQL 经验的团队来说，PlanetScale 提供的服务每月 39 美元是合理的。正确的比较不是与免费的 D1，而是与容量增长时手动管理 MySQL 分片的成本进行比较。
Neon：具有无服务器计算的真正 PostgreSQL
Neon 提供 PostgreSQL — 不是一个兼容的子集，也不是具有 MySQL 接口的 SQLite，而是实际的 Postgres 运行时。当您需要的东西不存在于任何其他数据库中时，这种区别就很重要了[无服务器6：用于地理空间数据的 PostGIS、1用于模糊文本搜索、2用于自动表分区、TimescaleDB 用于时间序列、SQLite 执行但有限制的复杂窗口函数。
Neon 的无服务器计算模型（在没有查询时扩展到零）对于具有零星流量的应用程序来说处于一个有趣的位置：只有当数据库被主动访问时，您才需要为计算付费。 Pro 套餐费用为 19 美元/月，包含 10GB 存储空间。对于已经拥有 PostgreSQL 代码并需要无服务器数据库而不迁移 SQL 方言的团队来说，Neon 是最直接的路径。
与 Cloudflare Workers 环境中的 D1 相比，Neon 的缺点是：Neon 使用通过标准 PostgreSQL 连接字符串访问的连接池程序（Neon 代理）。没有像 D1 那样的本机绑定。建立与 Neon 代理的连接的延迟取决于您配置的 Neon 区域以及 Worker 的运行位置 — 根据拓扑的不同，延迟可能为 10 毫秒或 80 毫秒，而 D1 的延迟为亚毫秒级。
三者之间的迁移成本
在项目开始时选择数据库会产生隐性成本，只有在选择错误并且需要更改时才会出现。三大银行的迁移成本不对称。
从 D1 迁移到 Neon 在技术上是可行的，但并不简单：3 会以 SQLite 方言生成 SQL 转储，需要在导入之前将其转换为 PostgreSQL。支持大多数查询，但特定的 SQLite 行为（例如类型亲和性、AUTOINCRMENT 与 SERIAL 的语义、日期处理）需要根据具体情况进行审查。调整量取决于代码对 SQLite 特性的利用程度。
从 PlanetScale 迁移到任何其他数据库意味着从 MySQL 迁移到 SQLite (D1) 或 PostgreSQL (Neon) — 不同的方言具有足够的语法差异，需要真正的可移植性工作。如果代码使用具有 MySQL 特定语法、MySQL 字符串函数或其他专有功能的事务，则迁移成本会更高。
简化决策的规则：如果您使用 Cloudflare Workers 并且您的数据小于 2GB，则 D1 是正确的默认值。如果您从一开始就需要 PostgreSQL（用于扩展、与现有工具兼容、用于 SQLite 不能很好支持的查询），请从 Neon 开始，而不是稍后迁移。当需要 Vitess 水平扩展而不是入门价格时，PlanetScale 就应运而生。这三者都不能很好地解决分析工作负载 - 为此，Cloudflare 分析引擎或专门的 OLAP 数据库是最短路径。
另请阅读
- [电子邮件路由 vs Improvmx vs 转发电子邮件：诚实的比较77
- [Workers + D1 + KV + R2：在同一服务中组合绑定8
- [DNS 代理与仅 DNS：有何变化以及每种模式何时有意义9
- [KV、R2 与 Cache API：何时使用每个 Cloudflare10 存储层
- [Cloudflare D1：边缘的 SQLite 数据库 — 以及为什么“边缘”的含义并不像看上去的那样11
- [Cloudflare 负载均衡和地理转向：当 DNS 成为智能流量层12