Has anyone been running Prisma 5.4.2 / @prisma/client 5.4.2 on Node.js 24 in production?

[nitinsinghnaruka]

Has anyone been running Prisma 5.4.2 / @prisma/client 5.4.2 on Node.js 24 in production?

We have an existing mature Next.js application using:

• Prisma 5.4.2
• @prisma/client 5.4.2
• MariaDB/MySQL
• Linux x64
• OpenSSL 3.x

We are evaluating an upgrade from Node 20 to Node 24 while keeping Prisma unchanged.

We already tested Prisma 5.4.2 on Node 24.14.0 in an isolated environment against our staging MariaDB database. The following all passed:

• npm install after temporarily bypassing our application's exact Node-engine restriction
• prisma generate
• Prisma Client startup
• reads/writes
• transactions and rollback
• raw SQL
• Decimal/JSON/DateTime
• moderate concurrent queries
• Next.js production build/start
• Prisma-backed API request

No Prisma engine or OpenSSL errors occurred.

I understand Prisma 5.4.2 predates Node 24 and Node 24 is not explicitly documented as a supported runtime for that Prisma version.

Has anyone used this exact or similar Prisma 5.x + Node 24 combination in production?

If yes:

• which Prisma 5.x version?
• which Node 24 version?
• Linux/macOS/Windows?
• database?
• any Prisma engine/OpenSSL/runtime issues?
• any issues that appeared only under production load or after running for some time?

I'm specifically interested in runtime compatibility issues, not whether upgrading to a newer Prisma version is generally recommended.

[omerfarooqBM]

Short version: it will almost certainly run, but "runs" and "supported" are different things here, and the version gap is the actual risk — not Node 24.

Why your staging test passed

Prisma 5.x loads the Rust query engine as a Node-API library, not as a V8-linked native addon. Node-API is ABI-stable across Node major versions by design, so libquery_engine-*.so.node does not need to be rebuilt when you jump Node majors. That's the mechanical reason 5.4.2 loads cleanly on Node 24 even though it was built long before it existed — and it means your staging result isn't a fluke, it's the expected behaviour.

Why that isn't the same as support

• prisma@5.4.2 was published 2023-10-09. Node 24.0.0 shipped 2025-05-06, ~19 months later. That pair has never been in Prisma's CI matrix, so nobody has data on it, including Prisma.
• prisma@5.4.2 declares engines: { "node": ">=16.13" }. That open-ended range is why npm stays quiet — it's not a support claim, it just predates the versions you're asking about.
• Current docs: v7 lists ^20.19.0, ^22.12.0, or ^24.0.0; v6 lists 16.13 / 18.X / 20.X (no 24); v5 isn't in the system requirements table at all anymore.

So Node 24 is only explicitly supported from Prisma 7 onward.

The risks I'd actually worry about in production

1. You're 18 patch releases behind inside your own major. The last 5.x release was 5.22.0 (2024-11-05), and there's been nothing on the 5.x line since. Between 5.4.2 and 5.22.0 there are connection-pool and engine fixes you don't have, and no security patches are landing on 5.x. This is a much bigger exposure than the Node version.

2. OpenSSL resolution, on your Linux x64 + OpenSSL 3.x setup. When Prisma can't resolve the system OpenSSL version it falls back to 1.1.x, which surfaces as Unable to load Node-API Library ... library may be corrupt. Two things worth knowing: it fails on first query rather than at build time, so a green build tells you nothing; and it's triggered by a base-image change, not by load. Pin it explicitly so an image bump can't surprise you:

   generator client {
     provider      = "prisma-client-js"
     binaryTargets = ["native", "debian-openssl-3.0.x"] // match your actual base image
   }

3. Load-related failures would come from the stale patch level, not Node 24. Node-API doesn't degrade under concurrency; an old pool bug does.

What I'd do

• Cheapest safe option: stay on Node 22 LTS. It's inside every documented 5.x/6.x window, and it buys you time without touching Prisma.
• Actually fixing it: go 5.4.2 → 5.22.0 first. It's in-major, so breakage should be minimal, and it gets you the full 5.x fix set — then move to Node 24.
• If you're already planning an ORM bump: Prisma 7.x lists Node 24 explicitly, and as of v7 the TypeScript query compiler is the default with no Rust binaries, which removes the binary-target/OpenSSL failure class from item 2 entirely.

Running 5.4.2 on Node 24 isn't going to blow up on you tomorrow — but you're carrying an unsupported, unpatched combination to save an upgrade that's mostly mechanical. I'd spend the afternoon on 5.22.0.