全部文章
2026-08-28FlareStarter Teamengineeringdrizzleprismacloudflarecomparison

Drizzle vs Prisma——到了 Cloudflare D1 上，这个对比完全变了

在 Postgres 上这是口味之争，在 D1 上不是：Prisma 的 D1 支持处于 Preview，而且会静默丢掉事务语义，而 D1 本身其实是有事务性批处理的。依据两家官方文档核实。

通用版的「Drizzle vs Prisma」已经被写过一百遍了：Prisma 有 schema DSL 和 Studio，Drizzle 更贴近 SQL、更轻，按口味选。在 Postgres 上这大致正确，也大致不重要——两个都不错，团队偏好是个正当的决胜依据。

但到了 Cloudflare D1 上，这就不是口味之争了。而且几乎没人写这一版，因为拿这两个 ORM 做对比的人大多在 Postgres 上。

FlareStarter Pro 在生产环境用 Drizzle 跑 D1。下面是两个项目的官方文档截至 2026-08-23 实际怎么说的。

Prisma 的 D1 支持处于 Preview

来自 Prisma 自己的文档：对 Cloudflare D1 的支持处于 Preview。它通过 @prisma/adapter-d1 驱动适配器配合 sqlite provider 工作。

Preview 不是贬义词——很多 Preview 特性实际用起来没问题。但它把预期摆正了：这不是 Prisma 优化的主路径。它们的边缘部署指南推荐 Prisma Postgres——「在边缘运行时上完整支持」——并且总体上引导你使用基于 HTTP 的驱动。

Drizzle 把 D1 当一等公民：专门的适配器、有文档的配置路径、drizzle.config.ts 里的 d1-http driver。

那条没人说准确的事务细节

这一段值得仔细读，因为「Prisma 在 D1 上没问题」和「D1 没有事务」两派都是错的。

Prisma 文档说：「Cloudflare D1 目前不支持事务。」因此在 Prisma 里，隐式和显式事务会被忽略，作为单条查询分别执行。

Cloudflare 文档说：「批处理语句就是 SQL 事务。如果序列中某条语句失败，会针对该语句返回错误，并中止或回滚整个序列。」

两句都是真的，合在一起说出了比任何一句单独更锋利的东西：

  • D1 确实有事务语义——通过 batch()，失败会回滚。
  • D1 缺的是交互式事务：没有让你跨多次往返自己驱动的 begin/commit/rollback。
  • Prisma 的事务 API 没有映射到 batch()。所以当你对着 D1 写一个 Prisma 事务时，它不会大声报错——那些语句只是各自单独执行了。

最后这条是危险的那条。读起来像事务的代码其实不是事务，而且没有任何东西提醒你。如果那段代码在动钱，你会从工单里知道这件事。

Drizzle 直接暴露 D1 的 batch()。你拿到的正是平台提供的语义，用平台自己的命名，中间没有一层抽象悄悄把「保证」翻译成「没有保证」。

整篇的论点浓缩成一句：在 D1 上，Prisma 的抽象在关键处是有损的，Drizzle 的不是。

迁移是两套不同的工作流

Prisma 在 D1 上不用 Prisma Migrate。它文档给的路径是用 prisma migrate diff 产出 SQL，再用 Wrangler 应用。你保住了 schema DSL，丢掉了迁移工具。

Drizzle 在 D1 上用 drizzle-kit generate 生成 SQL，通过 Wrangler 的 D1 迁移命令应用——FlareStarter Pro 就是这么做的：

pnpm db:generate          # drizzle-kit generate
pnpm db:migrate:local     # wrangler d1 migrations apply

两边都不神奇，最后都落到 Wrangler。但 Drizzle 那条是设计上就该走的路，而不是一份有文档的绕行方案，而且少了一个工具在假装自己的原生流程还成立。

两边都没你以为的那么成熟

诚实要求写上这条：Drizzle 目前是 v1.0 RC。 drizzle-orm 和 drizzle-kit 都是候选版本，不是稳定的 1.0。

所以 D1 上的真实局面是：一边是 Preview 适配器，一边是候选版本。如果「必须 1.0」是硬要求，两个都不合格——而且你大概也不该用 D1。

Prisma 真正赢的地方

不在 D1 上，但这些是真实的，而且比 D1 更常见：

  • schema DSL。 一个文件描述完数据模型，不写 SQL 的人也读得懂。Drizzle 的 TypeScript schema 更啰嗦、更难扫读。
  • Prisma Studio。 好用的 GUI，免费、免配置。Drizzle Studio 存在且不差，但 Prisma 的更成熟。
  • 关联查询的手感。 嵌套读写更干净。Drizzle 的关系 API 进步很大，但仍然更手动。
  • 成熟度与招聘。 用户更多、答案更多、已经会它的人更多。
  • Postgres 深度。 如果你在 Postgres 上——大多数 Prisma 用户都是——这篇文章关于 D1 的论证跟你完全无关。

Drizzle 赢的地方

  • 在 D1 上，决定性地赢，理由就是上面那条事务。
  • 可预测的 SQL。 查询构建器和最终发出的 SQL 贴得很近，你写的和实际跑的之间距离更小。
  • 没有独立的 schema 语言。 schema 就是 TypeScript，和你其余的类型天然组合。
  • 更轻的运行时体积，这在受限运行时里比在服务器上重要得多。

这些情况选 Prisma

  • 你在 Postgres 或 MySQL 上，想要最成熟的 TypeScript ORM。
  • schema DSL 和 Studio 对团队速度值真金白银。
  • 你希望嵌套关联读写是别人的问题。
  • 团队已经很熟它。

这些情况选 Drizzle

  • 你在 Cloudflare D1 上。 这不接近，理由就是那条事务行为。
  • 你希望 ORM 贴着 SQL，而不是浮在它上面。
  • 你希望 schema 和应用类型用同一种语言。
  • 你在受限运行时里，体积是真实预算。

结论

在 Postgres 上，随便选——为 schema DSL 争两句然后继续干活。

在 D1 上，选 Drizzle，但不是因为它更时髦。选它是因为 Prisma 的 D1 支持是 Preview、因为它们自己的文档推荐你在边缘换一个数据库、以及因为「一个静默地不是事务的事务」正是你在计费代码里承担不起的那类 bug。

抽象该隐藏的是复杂度，不是保证。

FlareStarter Pro 在生产环境用 Drizzle 跑 D1——只追加的 credits 账本、座位制订阅、以及每次动钱都带幂等 ref 的 webhook handler。

依据 Prisma 与 Cloudflare 公开文档核实于 2026-08-23。Preview 与 RC 状态恰恰是最会变的东西。