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.

[ssmurfgg04-gif]

A staging matrix like the one you ran is honestly worth more than the support table here. The query engine is a self contained native binary and does not embed Node, so the runtime surface that actually cares about the Node version is the JS client layer. Between 5.4 and current Node, that layer's behavior did not change in ways your matrix did not already cover: startup, transactions, raw SQL, Decimal, JSON and concurrency are exactly the risky spots and you tested all of them.

A few things I would still add before shipping it:

1. prisma migrate deploy plus db seed against a fresh database, not just queries over an existing schema.
2. A deliberate timeout and rollback case for interactive transactions if you use $transaction(async).
3. A sustained minute or two of high concurrency rather than a moderate burst, that is what catches event loop and pool regressions.
4. Graceful shutdown under in-flight queries, since process lifecycle and signal handling is one area that did change across Node majors.

One more angle worth weighing: 5.4.2 is from 2023. It clearly works, but if you ever hit an engine bug on Node 24 you will be debugging an engine that predates that runtime by two years. Moving to the latest 5.x is usually a drop-in change and gets you engines built and tested much closer to current Node. Not required for this upgrade, but it shrinks the blast radius if anything does go wrong in production.

[rsheth8]

Prisma 5.4.2 was not built or tested against Node.js 24, and running it there is risky — particularly for the query engine binary.

The core issue is that Prisma 5.x ships prebuilt native binaries for the query engine. Node 24 ships with a newer V8 and changed some native addon ABI constraints. Prisma did not publish Node 24-compatible binaries until the 5.x series was well past 5.4.2.

What we have seen in practice:

• The JS client layer usually works fine.
• The native binary (libquery_engine) may fail to load or segfault on Node 24, especially on Linux x64 with OpenSSL 3.x (which you have).
• MariaDB/MySQL users are slightly more exposed because the MySQL connector path exercises more of the native engine.

Recommendation: If you cannot upgrade Prisma, stay on Node 20 LTS. Node 20 is supported until April 2026, so you have time.

If you want Node 24, upgrade Prisma to at least 5.22+ (which added explicit Node 24 support) or better yet 6.x / 7.x which switched to a TypeScript-first engine and dropped the problematic native binaries entirely. The 5.x → 6.x migration is straightforward for most apps — the main breaking change is the output path for the generated client.