Next.js App Router搭配Drizzle ORM：Cloudflare Pages与Vercel部署对比及可行性

核心结论 #

可以在Cloudflare Pages上使用Drizzle ORM进行运行时查询，但需要针对Edge Runtime的限制做针对性适配。

Cloudflare Pages上的适配要点 #

• 数据库连接适配：Edge Runtime不支持net模块的直接TCP连接，因此不能用Postgres/MySQL等数据库的原生TCP客户端。可行方案包括：
  • 采用Cloudflare D1作为数据库，直接使用drizzle-orm/cloudflare-d1绑定，这是最贴合Cloudflare生态的方案
  • 选择支持HTTP/HTTPS访问的数据库服务（如Supabase REST API、PlanetScale HTTP代理），通过Drizzle的HTTP兼容客户端连接
• 迁移流程调整：Edge环境无法通过fs读取本地迁移文件，因此迁移必须离线完成：
  • 本地使用drizzle-kit generate生成迁移文件，再通过drizzle-kit push或数据库控制台手动执行迁移
  • 集成到Cloudflare Pages的CI/CD流程中，在部署前自动完成迁移操作
• 依赖包选择：确保使用Drizzle的Edge兼容版本，核心drizzle-orm包本身支持Edge环境，但要避免引入依赖Node.js核心模块的第三方插件或客户端。

与Vercel部署的差异与影响 #

运行环境灵活性 #

• Vercel默认提供完整Node.js Runtime（也支持手动切换到Edge），可以直接使用Drizzle的全部功能：包括通过TCP连接任意兼容数据库、在运行时读取本地迁移文件（虽然生产环境不建议这么做），无需额外适配
• Cloudflare Pages强制使用Edge Runtime，必须严格规避Node.js核心模块依赖，数据库连接方式受限

迁移执行方式 #

• Vercel上技术支持在Server Actions或API路由中触发迁移（仅适合开发/测试场景）
• Cloudflare Pages上无法在运行时执行迁移，必须提前完成离线迁移

性能与场景适配 #

• Cloudflare Pages的Edge Runtime冷启动速度更快，全球边缘节点分发，适合低延迟、高并发的轻量查询场景
• Vercel的Node.js Runtime冷启动相对较慢，但对于依赖Node.js生态的复杂业务逻辑、大计算量查询场景支持更灵活

数据库选择范围 #

• Cloudflare Pages更适配Cloudflare D1、Supabase（HTTP API）、PlanetScale（HTTP代理）这类无需TCP连接的数据库服务
• Vercel兼容所有Drizzle支持的数据库（Postgres、MySQL、SQLite等），可直接使用原生客户端建立TCP连接

内容的提问来源于stack exchange，提问作者user42195