Prisma 7.8.0: query plan cache control and PostgreSQL fixes that matter in real apps

TL;DR: Prisma 7.8.0 does not make a big scene, but it tightens the things that hurt real teams: queryPlanCacheMaxSize, fixes for PostgreSQL JSON filters, migrations, and introspection. It is exactly the kind of release that is easy to ignore and then blame later when memory grows on prod or a PostgreSQL edge case starts acting like a stubborn cat again.

Problem / Context

Most Prisma issues do not look dramatic on the first screen. They usually start quietly:

queries work, but load keeps rising;
migrations pass on staging and behave differently on local;
one JSON filter throws a weird error;
introspection does not pull quite what you expected back into a Prisma schema.

Prisma 7.8.0 touches exactly those cases. The release adds one new performance knob and closes several PostgreSQL bugs that looked minor on paper but become very real in a live application.

What changed in Prisma 7.8.0

1. You can now control the query plan cache

Prisma Client now supports queryPlanCacheMaxSize. That lets you control the size of the query plan cache.

What that means in practice:

if the same query shape appears again and again, the cache can help performance;
if your app produces a lot of distinct queries, a very large cache can waste memory;
if you want to disable the cache entirely, you can pass 0.

This is not a magic “make it faster” button. It is a tool for teams that already look at workload profiles instead of trusting intuition and coffee.

2. PostgreSQL JSON filters became less brittle

Prisma 7.8.0 fixes several PostgreSQL-specific bugs:

equality filters on JSON list columns no longer panic or emit the wrong ::jsonb cast;
case-insensitive JSON filtering with mode: insensitive now works correctly;
@map on enum values no longer breaks parameterization;
the P2029 parameter limit check is now more correct.

In plain language: if your backend works heavily with JSON, filters, and enums, this release has very concrete value.

3. Migrations and introspection are calmer now

A few more important fixes landed here:

prisma migrate diff no longer shows the stale --shadow-database-url message;
prisma migrate dev on PostgreSQL now handles CREATE INDEX CONCURRENTLY more reliably;
introspection no longer drops sequence defaults when PostgreSQL returns schema-qualified nextval(...).

These are the bugs you do not see in demos, but you absolutely do see on a bad release evening.

Why this matters

If you run Prisma + PostgreSQL, this release affects three areas at once:

Performance queryPlanCacheMaxSize gives you real control over what Prisma keeps in memory.
Query correctness JSON filters, enum values, and parameter handling are now more predictable.
Safer migrations CREATE INDEX CONCURRENTLY, the shadow database, and introspection are all things you want to re-check now, not during a late-night hotfix.

Short version: Prisma 7.8.0 is not just a version bump. It removes several small but annoying risks from PostgreSQL-backed projects.

How to approach it without surprises

1. First map where Prisma actually matters in prod

Before upgrading, check:

which services actually use Prisma Client;
whether you are on PostgreSQL;
whether you query JSON fields;
whether you have migrations with index creation;
whether you rely on db pull or other introspection flows.

If you do not know where Prisma is most important, you can easily do a “successful” upgrade and miss the riskiest spots.

2. Upgrade Prisma in a separate branch

Do not mix this with schema refactors, new models, and test polish. One diff, one brain.

A minimal flow looks like this:

npx prisma -v
npx prisma generate
npx prisma migrate dev
npx prisma db pull

Then run your unit, integration, and smoke tests against real PostgreSQL data, not only mocks.

3. Tune the cache only after measurement

If you want to try queryPlanCacheMaxSize, start from the default behavior and compare it with a few bounded values on staging.

Useful things to watch:

p95 / p99 latency;
RSS or other process memory;
how many repeated queries you actually have;
whether you really have many different query shapes.

If most queries are the same, the cache is usually helpful. If your queries constantly vary, the cache may not buy you much.

4. Run PostgreSQL edge cases separately

Create a small smoke suite for:

JSON equality;
mode: insensitive on JSON;
enum fields with @map;
a migration with CREATE INDEX CONCURRENTLY;
db pull on a schema with sequence defaults.

That is not paranoia. It is cheaper than discovering one wrong condition in production.

5. If you have access to real traffic, compare before and after

After the upgrade, do not only check “build is green.” Check:

API behavior under real traffic;
response times for the most common queries;
PostgreSQL error counts;
process size;
migration stability in staging.

What not to do

Anti-pattern 1. Turn on the new cache knob blindly

If you set a value without a metric, you may gain nothing or simply move the problem from CPU to memory.

Anti-pattern 2. Treat the release as “just fixes”

Fixes are often what save prod. These ones are very practical: JSON, enum values, concurrent index creation, introspection.

Anti-pattern 3. Skip migrations as a separate check

migrate dev and db pull are not decorative commands. If you use them, they deserve a real post-upgrade run.

Anti-pattern 4. Mix the Prisma upgrade with a schema revolution

When one PR contains a new version, new models, new indexes, and new tests, nobody can later tell what actually broke the release.

Conclusion / action plan

Prisma 7.8.0 is a good moment to do two things:

move the version forward without drama;
honestly check whether your PostgreSQL setup was sitting on one of the fixed edge cases.

The smartest path is:

upgrade in a separate branch;
run Prisma commands and your tests;
check JSON filters and migrations;
only then decide whether queryPlanCacheMaxSize deserves tuning.

Short version: do not turn the knob until you know what it controls.

Official source:

Prisma 7.8.0 release