Turso 与 Cloudflare D1 对比
当你需要成千上万多数时间闲置的数据库、需要部署在自己的云内、或需要边缘侧微秒级本地读取时，选 Turso——注意它现已并入 Supabase。当你已经跑在 Workers 上、希望零运维 SQLite 且不收出口流量费时，选 Cloudflare D1，但要接受单库容量硬上限无法提升。
Turso 用 Rust 把 SQLite 重写为 libSQL，其平台为按租户与按智能体的数据库集群而设计——按需加载、闲置挂起，并可运行在客户自己的云内。Cloudflare D1 是托管的无服务器 SQLite 数据库，可从 Workers 或通过 HTTP API 访问，查询停止即停止计费，且不收数据传输费。两边的约束点不同：Turso 按集群存储、行数与同步量计费，公开的是计划级存储额度；D1 则受制于无法提升的单库容量硬上限、单库内的单线程执行，以及仍处于 Beta 且必须走 Sessions API 才生效的全球只读复制。Turso 正在并入 Supabase：官方声明现有用户不受影响，Supabase 继续深耕 Postgres，Turso 继续深耕 SQLite。
适用边界: 按租户或按智能体的数据库集群、在虚拟机/VPS/移动端做本地优先读取、以及必须部署在自有云内的团队。
适用边界: 已经跑在 Workers 上、希望零运维 SQLite、需要全球只读副本、且希望流量停止即停止计费的应用。
- 单库容量上限
- 计划级存储额度（Pro 为 50 GB） vs 单库 10 GB 硬上限Cloudflare D1 限额 — 单库最大 10 GB 且不可提升
- 闲置数据库计费
- 仅计存储 vs 不计计算Turso 定价页 — 闲置数据库只计存储
- 每百万行读取单价
- 阶梯单价 vs 每百万行 $0.001Cloudflare D1 定价页 — 写入计费与免费档日限额
- 每百万行写入单价
- 阶梯单价 vs 每百万行 $1.00Cloudflare D1 定价页 — 写入计费与免费档日限额
交互式场景权重演算器
下面四个维度是本组矩阵自己的评估口径，不是一套固定分类。权重表示每个维度对你当前场景的重要程度；拟合度是三档评级的加权平均，不是实测基准。
可自行托管的可移植集群 vs 平台托管的无服务器方案及其单库硬上限
大量多数时间闲置的数据库要花多少钱，以及读取与写入量如何计价
能恢复到多久之前，以及恢复操作是否被限流
两种设计各自在哪里停止扩展，以及运维需要记住什么
在你分配的权重下 Turso 得分更高；Cloudflare D1 则在其他约束为主的场景中适用。
| 评估维度 / 考量权重 | Turso (定性评估与实证) | Cloudflare D1 (定性评估与实证) |
|---|---|---|
部署形态与架构主权 可自行托管的可移植集群 vs 平台托管的无服务器方案及其单库硬上限 基准权重:30% | Turso首选推荐 Turso 用 Rust 把 SQLite 重写为 libSQL，数据库按需加载、闲置挂起，既可跑在 Turso Cloud，也可部署在客户自己的云内。嵌入式副本把只读副本放进应用进程，读取直接从本地文件解析、耗时在微秒级。但在把新项目的核心押在这种形态上之前，有两件事要知道：Turso 正在并入 Supabase；且对于需要同步的新项目，Turso 现已推荐改用 Turso Sync，而非嵌入式副本。 权威出处:Supabase 收购 Turso 公告（现有用户无变化；Supabase 继续 Postgres、Turso 继续 SQLite）Turso 嵌入式副本（已可用于生产；新项目推荐 Turso Sync）Turso 定价页横幅（并入 Supabase 的官方声明入口） “For existing users, nothing changes. Supabase will continue building around Postgres, while Turso will continue its work on SQLite.”（原文） “Embedded Replicas are fully supported in production. For new projects that need sync, we recommend Turso Sync.”（原文） “Turso is joining Supabase to give every agent its own database”（原文） | Cloudflare D1有条件采纳 D1 既可从 Workers 访问，也可通过 HTTP API 访问，设计上支持以零额外成本创建数千个数据库做隔离，并内置灾难恢复。全球只读复制会在各区域放置只读副本，但它标注为 Beta，且只有查询走 D1 Sessions API 时才生效——否则全部由主库执行。此外每个数据库还有 Cloudflare 明确表示不可再提升的容量上限。 权威出处:Cloudflare D1 产品概述（Worker 与 HTTP API 访问、内置灾难恢复）Cloudflare D1 只读复制（跨区域只读副本降低读取延迟）Cloudflare D1 只读复制（必须走 Sessions API 才生效）Cloudflare D1 限额（单库最大 10 GB 且不可提升） “D1 is Cloudflare’s managed, serverless database with SQLite’s SQL semantics, built-in disaster recovery, and Worker and HTTP API access.”（原文） “D1 read replication can lower latency for read queries and scale read throughput by adding read-only database copies, called read replicas, across regions globally closer to clients.”（原文） “To use read replication, you must use the D1 Sessions API, otherwise all queries will continue to be executed only by the primary database.”（原文） “Maximum database size 10 GB (Workers Paid) / 500 MB (Free)”（原文） |
成本模型与闲置经济性 大量多数时间闲置的数据库要花多少钱，以及读取与写入量如何计价 基准权重:25% | Turso首选推荐 闲置数据库只计存储费，因此大量多数时间闲置的集群依然便宜；时间点恢复与数据库分支不产生用量费用。档位从 Free 到 $4.99/月 的 Developer（数据库数量不限），再到 Scaler 与 Pro，超出部分的单位费率随档位上升而下降。Turso 公开的是计划级存储额度，而非单库容量上限。 “Idle databases cost only storage, so a large fleet of mostly-idle databases stays cheap. Point-in-time restore and database branching do not add usage cost.”（原文） | Cloudflare D1有条件采纳 D1 只按读取行数、写入行数与存储计费，闲置计算不收费，也不收数据传输或出口流量费；付费计划在按百万行计费之前包含很大的月度读取额度。需要提前规划的不对称在于：写入每百万行 $1.00，而读取每百万行 $0.001；超出包含量的存储按 GB-月另行计费。 权威出处:Cloudflare D1 定价页（读取计费与免费档日限额）Cloudflare D1 定价页（写入计费）Cloudflare D1 定价页（存储单价）Cloudflare D1 定价页 FAQ（不收出口流量费） “Rows read 5 million / day First 25 billion / month included + $0.001 / million rows”（原文） “Rows written 100,000 / day First 50 million / month included + $1.00 / million rows”（原文） “Storage (per GB stored) 5 GB (total) First 5 GB included + $0.75 / GB-mo”（原文） “Does D1 charge for data transfer / egress? No.”（原文） |
恢复与韧性边界 能恢复到多久之前，以及恢复操作是否被限流 基准权重:25% | Turso首选推荐 时间点恢复深度随档位提升——Free 为 1 天，Developer 保留 3 天，Scaler 为 14 天，Pro 为 30 天；删除数据库的恢复窗口按档位分别为 10 天、30 天与 90 天。恢复操作不计入用量，因此演练恢复不会推高账单。 “Point-in-time restore and database branching do not add usage cost.”（原文） | Cloudflare D1有条件采纳 D1 内置灾难恢复与 Time Travel 时间点恢复，在同等价格下比 Turso 的低档位保留更深。约束在吞吐：恢复操作按「每库每时间窗」限流，会对集群级恢复造成节流。 “Time Travel duration (point-in-time recovery) 30 days (Workers Paid) / 7 days (Free)”（原文） “Maximum Time Travel restore operations 10 restores per 10 minutes (per database)”（原文） “D1 is Cloudflare’s managed, serverless database with SQLite’s SQL semantics, built-in disaster recovery, and Worker and HTTP API access.”（原文） |
单库并发与运维摩擦 两种设计各自在哪里停止扩展，以及运维需要记住什么 基准权重:20% | Turso有条件采纳 嵌入式副本在本地以微秒级完成读取，并保证 read-your-writes；但在没有文件系统的无服务器环境里完全不可用，且在副本同步期间打开本地数据库会导致损坏。同步量也可能超出预期：任何一次导致内部 btree 在节点处分裂的写入，都会向复制日志写入大量新帧。 “Do not open the local database while the embedded replica is syncing. This can lead to data corruption.”（原文） “In certain contexts, such as serverless environments without a filesystem, you can’t use embedded replicas.”（原文） “Embedded Replicas keep a local read replica of a Turso Cloud database: reads run locally from the file in microseconds”（原文） | Cloudflare D1有条件采纳 每个 D1 数据库本质上是单线程的，一次只处理一条查询，因此吞吐随查询耗时变化。此外还有单条查询与单次调用层面的上限：最长查询时长、单行或 BLOB 最大大小、每表列数上限等。账户级上限很高（可创建大量数据库、总存储额度大），因此压力集中在单库而非整个集群。 “Each individual D1 database is inherently single-threaded, and processes queries one at a time.”（原文） “Maximum number of columns per table 100 Maximum number of rows per table Unlimited (excluding per-database storage limits)”（原文） “If your average query takes 1 ms, you can run at most 1,000 queries per second.”（原文） |
何时应当坚决放弃对应技术栈
任何技术架构均伴随特定妥协。如果您的业务命中了以下触发条件，引入该工具将带来不可控的工程债务而非杠杆效能。