Invocation of prisma failing in staging deployment
I have upgraded both prisma and @prisma/client to v 6.16.1 , set it up correctly following the docs and everything is working fine in development but in staging environment.
For context I have a :
monorepo set up with turborepo,
api directory under apps/api, nest.js with graphql ,
local db using postgres with docker
staging api deployed to render using prisma postgres as staging db
On render :
build command : pnpm install --frozen-lockfile && prisma generate && nest build
start command : cd apps/api && prisma db push && node dist/src/main
the deployment is successful and the the client is generated as expected, but can't make any query or mutation. For instance trying to query countries as per mys schema would throw an error :Invalid this.db.country.findMany() invocation in /opt/render/project/src/apps/api/dist/src/countries/countries.service.js:105:42 102 meanwhile I have no issue locally. Not sure what I am missing.
NOTE: everything was working fine both locally and in staging , I just updated my client generation logic to use rust-free, upgraded prisma and prisma client dependencies, added pg adpater, modified my database service and manually updated the path to import PrismaClient, models, enums types from the generated folder located under apps/api/src/generated
12 Replies
Skipping coffee for instant knowledge! Let's brew that AI answer now.
1- apps/api/prisma/schema.prisma
generator client {
provider = "prisma-client" // ESM-first
engineType = "client" // No rust engines
output = "../src/generated/prisma"
}
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
2- apps/api/database/database.service.ts
3- apps/api/countries/countries.service.ts
Based on your description, the issue likely relates to the new Rust-free Prisma Client setup with the queryCompiler and driverAdapters preview features in a monorepo/turborepo environment. This setup is known to cause deployment/runtime issues in certain environments, especially when the generated Prisma Client is not in the default location or when the .wasm file (query_compiler_bg.wasm) is not found at runtime.
Key points from the knowledge sources:
- When using the Rust-free setup (
previewFeatures = ["queryCompiler", "driverAdapters"]), Prisma generates a .wasm file that must be available at runtime. In monorepo setups, the client may look for this file in the wrong directory, especially in production or serverless environments, leading to errors like the one you described (Prisma Postgres Adapter with Turborepo does not work).
- This is a known issue, and several users have reported that the generated client tries to resolve the .wasm file relative to the current working directory, not the actual location of the generated client. This causes ENOENT errors or failures to invoke queries in production, even if everything works locally.
- Workarounds include:
- Using the default output path for the Prisma Client (@prisma/client) instead of a custom output path, if possible.
- Ensuring that the .wasm file is copied to the correct location in your build output, or manually patching the generated client to resolve the path correctly (not ideal for CI/CD).
- Some users have found that switching back to the Rust engine (removing the preview features) resolves the issue, but this defeats the purpose of the Rust-free setup.
- Prisma is actively working on improving this, and newer versions may address some of these path resolution issues, but as of v6.16.1, this is still a common pain point in monorepos and serverless deployments ([Prisma Postgres Adapter with Turborepo does not work](<https://github.com/GitHub
GitHub · Build and ship software on a single, collaborative platform
Join the world's most widely adopted, AI-powered developer platform where millions of developers, businesses, and the largest open source community build software that advances humanity.
prisma/prisma/issues/27083>)).
Recommendation:
If you must use the Rust-free setup, double-check that the .wasm file is present in the expected location in your staging build output. If not, consider temporarily reverting to the Rust engine or using the default client output path until Prisma releases a more robust fix for monorepo deployments. There is no official, fully reliable workaround documented for this scenario as of your version. If you need more details or a step-by-step workaround, please specify your exact client import path and directory structure. 🤔 Alright, thanks for letting us know that there's still some help needed. A team member will reply to you shortly. In the meantime, please let us know any additional info, questions, or which parts of the answer may need clarification.
If you must use the Rust-free setup, double-check that the .wasm file is present in the expected location in your staging build output. If not, consider temporarily reverting to the Rust engine or using the default client output path until Prisma releases a more robust fix for monorepo deployments. There is no official, fully reliable workaround documented for this scenario as of your version. If you need more details or a step-by-step workaround, please specify your exact client import path and directory structure. 🤔 Alright, thanks for letting us know that there's still some help needed. A team member will reply to you shortly. In the meantime, please let us know any additional info, questions, or which parts of the answer may need clarification.
I am confused I thought the rust-free setup was "Ready for production" and also adding previewFeatures = ["queryCompiler", "driverAdapters"] throws "deprecated" as a warning in v6.16.1, here are some logs from deployment

Does the issue get fixed if you revert to older prisma version?
We have a turborepo example with the new prisma-client generator here, if it's helpful:
https://github.com/prisma/prisma-examples/tree/latest/generator-prisma-client/nextjs-starter-webpack-turborepo
Though the example is still on 6.14.0 version so previewFeatures are still needed
GitHub
prisma-examples/generator-prisma-client/nextjs-starter-webpack-turb...
🚀 Ready-to-run Prisma example projects. Contribute to prisma/prisma-examples development by creating an account on GitHub.
Thanks for the heads up. I was working with 6.10 and everything was working fine in both environments (local and staging) I had no issue, And I got excited with the new update allowing rust-free engine then i updated to v6.16.1, and no issue in local development but when deployed to staging for some reason I am getting those invocation errors not sure why.. the question is can i opt-in for the rust-free engine when being on 6.14.0 ? Because I really want to test the latency difference with the new version as my queries are slow. To be honest I was looking into migrating to drizzle for prod but I really love the DX with prisma and hope to fix this issue. So, would really appreciate if you could if you could test the new version with turborepo and confirm there is no issue. Maybe there is something missing in my setup, but again it's working with no issue locally which is weird, the only difference is the database url between the two environments.
the question is can i opt-in for the rust-free engine when being on 6.14.0 ?Yes, you can. You would need to enable queryCompiler and driverAdapters as shown here: https://github.com/prisma/prisma-examples/blob/latest/generator-prisma-client/nextjs-starter-webpack-turborepo/packages/database/prisma/schema.prisma
hi, has this been fixed?
I keep running into these issues
get off the rust engines if you havent already
that’s exactly what I’m trying to do lol
I. keep running into issues
Not for me. I reverted back to having prisma-client-js as provider without any output folder. I suspect that having the output folder does not work well in a monorepo on production, I kept getting the same issue. It's working fine locally though which is annoying