Replies: 5 comments 5 replies
|
Great observation! This is a common pain point with ORMs that support multiple databases - the trade-off between flexibility and bundle size. Your suggestion about database-specific packages makes sense. Some approaches the Prisma team could consider:
Would love to see this addressed - 75% reduction would be significant for serverless deployments! |
|
Why are you plugging your own totally unrelated service in this discussion? |
|
You are addressing the issue of large bundle size in // Potential solution for tree-shaking database-specific query compiler files
// Currently, @prisma/client bundles all query compilers which leads to a large size
// Consider implementing a mechanism to only include necessary query compilers based on the configured providerBy default, Prisma includes all database query compilers, leading to a bloated bundle size. Implementing a mechanism to include only relevant query compilers based on the configured provider can significantly reduce the package size. Hope this sheds some light on the situation and potential improvements for Prisma! |
|
I'm sorry, but how does this contribute to the discussion? Did you just feed my post to an LLM? |
|
Sorry about the generic reply earlier. You are absolutely right, carrying 70MB of unused WASM binaries is painful. It's a side effect of the current architecture prioritizing zero-config setups. The team is aware of this modularity issue, and the roadmap for Driver Adapters (@prisma/adapter-pg, etc.) is likely the path that will finally allow tree-shaking those unused engines in the future. |
|
Thanks for flagging this. This seems like a valid package size feature request. From the file names, this looks related to Prisma 7’s Rust free client architecture. Instead of shipping native query engine binaries, Prisma now includes query compiler assets in the client runtime. In 7.3.0 specifically, Prisma also added a generator client {
provider = "prisma-client"
output = "../src/generated/prisma"
compilerBuild = "small"
}That may reduce the generated client footprint, although it does not fully address your main point: I agree the ideal outcome would be for the installed or generated client to include only the compiler needed for the configured datasource provider. For example, a PostgreSQL only project should not need MySQL, SQLite, SQL Server, or CockroachDB compiler assets in its installed package or deployment artifact. Moving those assets into provider specific packages or adapter packages sounds like a reasonable direction, although there may be some internal constraints around generation, bundling, edge runtimes, or dynamic provider resolution. A useful issue title might be: And the core request could be: As a temporary mitigation, projects can try |
|
Those Right now the best you can do is add generator client {
provider = "prisma-client-js"
compilerBuild = "small"
}This switches from the There's no official way yet to install only the compiler for your specific database provider — it's shipped as a bundle to keep the zero-config setup working. This is a known pain point and Prisma is tracking it, the direction being to eventually move these into provider-specific packages so you only pay for what you use. Until then, |
|
کد فلیتر روبیکا فوری |
|
I'm on 5g |
|
@jaendmzgb1645-ux chortle on my balls man |
Uh oh!
There was an error while loading. Please reload this page.
Question
Hi!
I noticed that
@prisma/clientversion7.3.0comes in at a quite sizeable 74 MB when installed. Upon further inspection, I found that 69 MB of this comes from files of the formquery_compiler_*.wasm-base64.*, which (as the naming suggests) presumably contain lots of base64-encoded WASM.That's all fine, but what I think is unfortunate is that there are such files for every supported database (CockroachDB, MySQL, PostgreSQL, SQLite, and SQL Server), whereas I imagine the majority of projects only use one database, for instance PostgreSQL. Ideally, only the relevant query compiler files would be installed; taking PostgreSQL as an example, this would bring
@prisma/clientdown to 19 MB, i.e. a 75% reduction.As for how to achieve this, I'm not sure – I suppose the database-specific query compilers would have to be in separate packages? Would it be an idea to move them to the adapter packages?
I'm completely unfamiliar with Prisma's internals, so apologies in advance for any mistakes made, just thought I'd flag this.
All the best,
Ole
How to reproduce (optional)
mkdir prisma-test && cd prisma-testnpm install @prisma/client@7.3.0du -ah | sort -hr | head -n 30You should see output similar to the following:
Expected behavior (optional)
No response
Information about Prisma Schema, Client Queries and Environment (optional)
No response
All reactions