Why we pin Prisma to 6.x on Cloudflare Workers

If you run Next.js on Cloudflare Workers through OpenNext with Prisma, you've probably seen the update banner nudging you to Prisma 7. Don't take it — not yet, and not because of laziness. Here's the full story, plus two adjacent traps that produce equally cryptic errors.

Trap 1: Prisma 7 and "Wasm code generation disallowed"#

Upgrade to Prisma 7, deploy to Workers, and the first query throws:

CompileError: WebAssembly.instantiate(): Wasm code generation disallowed by embedder

Prisma 7's query compiler ships as WebAssembly that gets compiled at runtime. The Workers runtime forbids runtime WASM compilation outright — it's a security boundary of the platform, not a config flag you can flip. WASM on Workers must be a static import known at deploy time.

The pragmatic fix while the ecosystem catches up: pin all three packages to the same 6.x version — prisma, @prisma/client, and your driver adapter (in our case @prisma/adapter-pg):

{
  "dependencies": {
    "@prisma/client": "6.19.0",
    "@prisma/adapter-pg": "6.19.0",
    "prisma": "6.19.0"
  }
}

Exact versions, no ^. A lockfile refresh that silently bumps one of the three out of sync produces its own class of confusing errors.

Trap 2: a custom output path breaks the deploy#

Prisma's docs suggest generating the client into your own source tree:

generator client {
  provider        = "prisma-client-js"
  output          = "../src/generated/prisma"   // ← don't do this on OpenNext
  previewFeatures = ["driverAdapters"]
}

On OpenNext this dies at runtime with:

Error: No such module "node:os"

Why: OpenNext patches the Prisma client inside node_modules during its build to make it Workers-compatible. Generate the client anywhere else and the patch never lands — you ship the untouched Node build to a runtime that doesn't have all of Node. Remove the output line and let the client live in node_modules where OpenNext expects it.

Two related settings that need to agree with this:

// next.config.ts
serverExternalPackages: ["@prisma/client", ".prisma/client", "pg", "pg-cloudflare"],

// wrangler.jsonc — 2025-09-15 or later auto-enables the node:os / node:tty
// polyfills the Prisma client needs
"compatibility_date": "2025-09-15",

Trap 3: Prisma 6.x still wants url in the datasource#

Even when you connect exclusively through a driver adapter (so the schema URL is never used for queries), Prisma 6.x refuses to generate without it:

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")   // required by 6.x even with driverAdapters
}

Keep a DATABASE_URL around for prisma generate and migrations, even if production traffic flows through a completely different connection path.

Takeaways#

1. On Workers, treat Prisma major upgrades as platform migrations, not routine bumps. The runtime constraints (no runtime WASM, partial Node API) surface in Prisma's internals, not yours.
2. Pin exact versions across all Prisma packages. Adapter/client version skew is a real failure mode.
3. When a platform tool patches node_modules (as OpenNext does), stock configuration beats clever configuration. Custom output paths, aliases, and hoisting tricks all risk dodging the patch.

Previously in this series: Server Action hanging on Cloudflare Workers? Check your revalidatePath scope. Next up: reaching external Postgres from Workers when direct TCP won't connect.

Fenix Codex builds and operates production web platforms — get in touch if you need a team that debugs at this depth.