什么时候该离开 Cloudflare D1？

D1 不是“小玩具”，但它的边界很明确，而且都写在官方限额里：单库大小有上限，每个库一次只处理一个查询，也没有交互式事务。

当你的数据无法自然拆成多个库、写入需要高并发，或者业务逻辑里全是“读-判断-写”时，就该离开 D1。 其余情况，读多写少的内容站、按租户隔离的小库、需要 SQL 与约束的业务后台，它很合适。

下面逐条讲这些边界各自意味着什么，离开时去哪里，以及留在 D1 时的几条实践建议。

单库能放多大？

Paid 是 10 GB，官方明确不可提高；Free 是 500 MB。

文档建议拆多个库。按租户或用户分库可行，但跨库查询要自己做。无法自然分库的单体大表，应考虑其他数据库。

每个库单线程意味着什么？

官方文档说每个库一次只处理一个查询，吞吐取决于查询耗时，所以慢查询会堵住其他请求。写密集、需要高并发写入的系统会先撞到这里。

这一点我没有在线上测过，只是官方的说法。

没有交互式事务怎么办？

D1 的事务单位是 batch()，不能在中间读值、判断、再写。需要大量“读-判断-写”的业务逻辑，用 Durable Objects 更合适，它的 storage 有事务 API。D1 这边的做法见 Cloudflare D1 怎么做事务？。

已经有 Postgres 或 MySQL 呢？

不必迁移。官方的建议是用 Hyperdrive 做连接池与缓存即可。

留在 D1 要守什么习惯？

• 给每个查询检查 meta.rows_read 与 meta.rows_written。D1 按这两项计费，缺索引的全表扫描会直接体现在账单与耗时上；
• 在 schema 里用 NOT NULL、UNIQUE、CHECK 和外键表达不变量。

还没选定存储的话，先看 存储怎么选。

上面的单库上限、单线程说法、Hyperdrive 建议，以及 rows_read / rows_written 的计费口径，都来自官方文档，我没有在线上验证。限额会变化，以 2026-10 的官方文档为准；官方限额页见 https://developers.cloudflare.com/d1/platform/limits/。