Three facts about running Prisma on Cloudflare Workers that I learned the expensive way, debugging out-of-memory kills on a large production API:
1. Every concurrent Prisma client costs real memory. On a schema with 187 models, each client compiled the schema inside WASM at roughly 3.8 MB per concurrent client. Ten concurrent database-touching requests ≈ 38 MB, on top of a fixed floor of bundle plus query-compiler WASM — before any actual work happens, and all inside a 128 MB isolate.
2. The schema compile is synchronous. It blocks the isolate thread while it runs. The tell we almost misread: “cheap” endpoints — a query over a 30-row table — taking multiple seconds with an empty queue. That’s not a slow database; it’s the thread busy compiling schemas for other requests.
3. WASM memory never shrinks. memory.grow() is one-way. So an isolate’s memory footprint is set by its historical peak concurrency and stays there for the isolate’s life. A single burst of fifteen simultaneous requests permanently raises that isolate’s floor, even if it never sees a burst again.
The consequence that reframed everything for me: a request is not cheap because its response is small. We had ~200-byte responses killing isolates, because the cost driver is concurrent client construction, not payload size. The number that matters is how many database-touching requests run at once — which makes frontend fan-out (how many calls a page fires on mount) an architectural concern for your backend’s memory, not a rendering nit.
Cap concurrent clients explicitly, count the fan-out per page, and keep queue consumers and crons off the request Worker entirely.