Prisma ORM Roadmap: March – May 2025

[wmadden]

3 Month Roadmap: March, April, May

This quarter, our two major objectives are to deliver the Query Compiler to Preview and to enable the Prisma CLI to work in web contexts, such as StackBlitz or other web-based editors.

We’re also improving the developer experience by:

• Making Prisma-generated code ESM-compatible
• Splitting Prisma's generated output into multiple files instead of one large file
• Refining some tricky CLI commands (looking at you, migrate dev)

Our last major initiative is to finalize the Prisma 7.0.0 API and upgrade path. We’ll share more details over the next three months, aiming to go live with Prisma 7 in June (or thereabouts).

As always, we're addressing a curated list of high-priority community issues alongside these major projects — this time targeting around 30 issues.

1. Query Compiler Preview Release

Last quarter, we implemented a core subset of the Prisma Client API using the new Query Compiler architecture. Read more about its performance benefits.

The initial work validated our approach and allowed us to benchmark performance improvements. This quarter, we’re bringing those benefits to the community by releasing the Query Compiler in Preview, one database at a time. More details will follow with each release.

Query Compiler is released in Preview and supports:

• Prisma Postgres
• Postgres
• MySQL
• SQLite
• MongoDB
• MariaDB

2. Enable the Prisma CLI In Web Contexts

Running the Prisma CLI in StackBlitz or similar environments currently fails because Prisma relies on native binaries compiled from our Rust codebase. This quarter, we’ll enable the CLI to work in web contexts by using WebAssembly (Wasm) instead.

This requires enabling the CLI to use Driver Adapters, similar to how the Prisma Client does. This will also unlock migration support for previously unsupported databases like SQLite and D1.

We’ll release the new CLI implementation into Preview this quarter, including Driver Adapters for all our First-Class Databases (and a few others).

Web-Compatible Prisma CLI released in Preview and supports:

• Prisma Postgres
• Postgres
• MySQL
• SQLite
• MongoDB
• MariaDB
• D1
• SQLServer

3. ESM Support, No More node_modules & Splitting the Output

Going forward, we’re deprecating the following behavior:

• A deprecation warning will appear unless you specify an output path for generated code
• Starting with Prisma 7, specifying an output path will be required

We're also improving code generation quality:

• Generated output will be split into multiple files instead of one large file
• Code will be ESM-compatible
• We will no longer generate a package.json — you can define it yourself if needed

These changes complement the Query Compiler work, as generated output will no longer include native Rust binaries, making the output smaller.

Finally, we’re removing Prisma’s automatic loading of .env files. The prisma.config.ts file allows you to manage environment configuration directly for CLI commands, and we believe your ORM shouldn’t handle this behavior for your production application. Currently, this behavior is already disabled if a config file is present but retained for backward compatibility. In Prisma 7, it will be removed completely.

Code generation with Prisma:

• Is ESM-compatible
• Outputs a deprecation warning if no output path is specified
• Outputs multiple files instead of one large file
• No longer includes package.json or other node_modulesspecific files

4. Preview Feature Updates

As we prepare for Prisma 7, we’re adjusting the timeline for several preview features:

schemaFolder → Moving to GA (with potential minor API changes)

deno → Deprecated (Prisma now works on Deno natively with ESM-compatible output)

metrics → Deprecated (will no longer function once the Query Compiler reaches GA)

postgresExtensions → Deprecated (it didn’t meet expectations — thanks for the feedback)

Preview feature updates:

• schemaFolder is in GA
• deno preview feature is deprecated
• metrics is deprecated (removed in v7)
• postgresExtensions is deprecated (removed in v7)

5. Address Highly-Upvoted Issues

Last quarter, we committed to resolving 5 highly upvoted issues. This quarter, we’re stepping it up — targeting at least 38 issues.

While we may not hit them all, we aim to close most of them. We’ll also address bug fixes and other unplanned issues along the way.

Issues addressed by Query Compiler

• Context propagation for query logging #7596
• prisma generate tries to fetch engine checksum files from mirror even if custom engine locations are provided in an .env file #12593
• Allow binaryTargets as a CLI option  #15267

Issues addressed by Web-Compatible CLI

• Support Migrations, Introspection, Studio for Driver Adapters only databases (e.g. Turso, Cloudflare D1) #22184
• __dirname is not defined when generating PrismaClient to custom location, w/ SvelteKit #15614
• Support for Cloudflare's new SQLite database D1 #13310

Issues addressed by ESM Support

• @prisma/nextjs-monorepo-workaround-plugin is not able to handle multiple clients #18069
• Importing enum in browsers results in `Error resolving module specifier “.prisma/client/index-browser”.  #12504
• Add support for Deno #2452
• Support ES6 modules export / ESM #5030
• ESM (.mjs) modules of TypedSQL client use CommonJS imports when generating to a non-default location #25259
• Unable to interop export * from "@prisma/client" in /home/[user]/Documents/[project]/packages/db/index.ts, this may lose module exports. Please export "@prisma/client" as ESM or use named exports instead, e.g. export { A, B } from "@prisma/client" #21474

Issues addressed by Driver Adapters

• Using Prisma NextJS edge runtime leads to error #18763
• Set default values for schema url fields #222

Issues addressed by promoting schemaFolder to GA

• Support for splitting Prisma schema into multiple files #2377
• bug(cli): prisma format does not format files other than schema.prisma when using prismaSchemaFolder preview feature #25136
• Feature: Remote schema #1563

Issues addressed by no more node_modules

• Module '"@prisma/client"' has no exported member 'PrismaClient'.ts(2305) #13672
• prisma generate, typings not updating in VSCode unless IDE is restarted. #14722
• prisma generate fails in yarn2 / yarn3 workspaces #8765

Issues addressed by no more .env loading

• Root .env variables aren't available to prisma in monorepo #12535
• Switch .env file based on NODE_ENV #3865
• importing prisma client pollutes process.env without using dotenv #19519
• Possibly reading .env file and schema twice #19117
• Add Support for More .env Files #3226
• Support multiple .env files natively #11050
• @prisma/client magically loading .env file (and mutating process.env in the process) #15620
• Change the default filename for loading environment variables to .env.local #15681

Some other issues we really want to address

• Running prisma migrate dev --create-only actually applies previous (non-deployed) migrations #11184
• migrate dev --create-only with empty schema but existing database schema detects drift and warns about deleting all data #6579
• Allow calling prisma migrate dev programmatically by adding --allow-non-interactive flag #7113
• prisma db reset that resets the database, pushes the schema, and runs the seed function #11261
• pnpm install not running prisma generate #6603
• Large schemas generate huge index.d.ts causing slow autocomplete and type-checking in your editor #4807
• Add option to skip unnecessary SELECT after create() #4246
• Client extensions that require use of a client-level method silently ignore transactions #20678
• Introspecting a part of existing database #807

[vimutti77]

Will switching query Compiler from Rust to Typescript reduce memory usage for large queries?

[Nabwinsaud]

What will be the migration journey from 6 to 7 for the application running in prod ?

[jharrell]

@vimutti77 @Nabwinsaud thank you both for your questions! We actually answered them live on our latest dev AMA

The TL;DR is that, yes, we do expect there to be some memory and CPU usage improvements in the new version, although not directly related to the switch from Rust to TS.

As for the migration journey: expect a standard upgrade guide like you have from 4 to 5, or 5 to 6. In addition to that, we'll recommend enabling a set of preview features so you have to change as little as possible. Finally, we're looking into a codemod or similar to help with the transition.

Thanks again for your questions!

[lorenzobalzani]

Hi, #3388 has been around for quite a while and has received a significant number of upvotes. Would now be a good time to consider adding it to the roadmap?

[kratos-respawned]

So now that postgresExtensions are deprecated, what is the ideal way to use PostGIS in a Prisma application, as my project heavily relies on it?

[hrithiqball]

what about other preview features? prisma is lacking behind drizzle in typedsql raw and joins should be default by now. also mongo migrate would be awesome

[andrewreid]

So now that postgresExtensions are deprecated, what is the ideal way to use PostGIS in a Prisma application, as my project heavily relies on it?

Ideally, we need to see a strategy for dealing with the myriad different extensions and different types the Postgres ecosphere is coming up with. It's frustrating to not be interact natively with those types. I'm finding the lack of pg_vector support a bit of a pain point at the minute – and I'm sure there are a bunch of other people with their own example.

[macrozone]

So now that postgresExtensions are deprecated, what is the ideal way to use PostGIS in a Prisma application, as my project heavily relies on it?

Ideally, we need to see a strategy for dealing with the myriad different extensions and different types the Postgres ecosphere is coming up with. It's frustrating to not be interact natively with those types. I'm finding the lack of pg_vector support a bit of a pain point at the minute – and I'm sure there are a bunch of other people with their own example.

I agree, I find the lack of pg_vector support very serious as well. Raw Queries and typed sql do not really help here, because you then give up a lot of prisma's DX.
Ideally prisma would not only allow you to declare Unsupported- db types in the schema (as it already allows you to do), but it would also provide a way to influence the query that is generated if you use such a type in the query.