Prisma ORM 7's Rust-free query engine speeds up queries and slows down cold starts

Prisma's own blog says its new query engine is 85-90% smaller and up to four times faster. I installed it next to the engine it replaces and measured both claims on my own machine. The speed claim held up almost exactly. The size claim did not: node_modules came out 31% bigger, not smaller.

Prisma ORM removed its Rust query engine in version 7, released in November 2025, in favour of a TypeScript/WebAssembly "query compiler" that talks to your database through a JavaScript driver adapter instead of a native binary. It's the default now on 7.10.1, which shipped on 15 October 2026, so most people upgrading from Prisma 6 this year are about to hit this change whether they asked for it or not. I wanted to know what it actually costs and saves, not what the migration guide says it costs and saves.

I built two identical projects, same two-model schema, same SQLite database, same seed data. One used prisma@6.19.3 with the classic prisma-client-js generator and its Rust engine. The other used prisma@7.10.1 with the new prisma-client generator, the @prisma/adapter-better-sqlite3 driver adapter, and a prisma.config.ts file, because the old url = "file:./dev.db" line in the datasource block is simply rejected now.

The number that matches the marketing

I ran 2,000 sequential findUnique calls against a table of 2,000 seeded users, three times each, after the connection was already warm.

That's a 3.1x speed-up, sitting right inside Prisma's own "three to four times faster" claim. I didn't expect a vendor number to hold up this cleanly, but for this specific shape of workload — a prepared single-row query run repeatedly on a warm connection — it did.

Inserts told a different story. Seeding the same 2,000 rows one at a time took 4,957-7,436 ms on the old engine and 4,181-7,093 ms on the new one, which is the same number inside measurement noise. Neither engine is the bottleneck for sequential writes to a SQLite file with default journalling; the disk and the journal mode are. Prisma's speed claims are about reads, and testing only reads would have made the post look better than the change actually is.

The number that contradicts the marketing

The 85-90% size reduction is framed around the query engine artifact itself: a 14 MB Rust binary against a 1.6 MB compiled TypeScript bundle. That comparison is real, but it isn't what lands in your project.

$ du -sb node_modules # prisma 6 project 266428327 node_modules # 254.1 MiB $ du -sb node_modules # prisma 7.10.1 project 349344415 node_modules # 333.3 MiB 

31% bigger, not 85-90% smaller. Some of that is the driver adapter and better-sqlite3's native bindings (27 MB), which Prisma 6 didn't need at all because the Rust engine spoke to SQLite directly. But most of it is that @prisma/client still ships a WebAssembly query compiler for every supported database, in two size tiers, "fast" and "small":

$ ls -la node_modules/@prisma/client/runtime/query_compiler_*sqlite* 4406183 query_compiler_fast_bg.sqlite.wasm-base64.js 2214935 query_compiler_small_bg.sqlite.wasm-base64.js 

The old engine's SQLite WASM fallback was 2,895,111 bytes. The new "fast" compiler for the same database is 4.4 MB — bigger, not smaller. Only the "small" variant comes in under the old number, and only by about 24%. Multiply either one by five supported databases and the per-provider bloat adds up before you ever bundle your app. The prisma CLI package has also grown: it now bundles @prisma/studio-core and an embedded Postgres (@electric-sql/pglite) for local development, which explains some of the extra weight but isn't something the size comparison on Prisma's blog post mentions.

What it refuses

Moving the connection string out of the schema file isn't a suggestion, it's enforced:

Error: Prisma schema validation - (get-config wasm) Error code: P1012 error: The datasource property `url` is no longer supported in schema files. Move connection URLs for Migrate to `prisma.config.ts` and pass either `adapter` for a direct database connection or `accelerateUrl` for Accelerate to the `PrismaClient` constructor. 

Construct the client with no adapter at all and you get a real error, not a crash buried three stack frames down:

PrismaClient was instantiated without any options. A driver adapter is required to connect to your database. 

And the old middleware API is gone outright:

> prisma.$use(() => {}) TypeError: prisma.$use is not a function 

The documented replacement, a query extension via $extends, does work as a drop-in. I wired up the exact pattern from Prisma's migration guide — intercepting user.create to log the call before running it — and it fired correctly on the first try, which is more than I expected given how much else in this release needed a workaround of its own.

One more packaging detail nobody warned me about: the generated client is TypeScript source, not compiled JavaScript. There's no client.js to require(). I had to run it with node --experimental-strip-types or a bundler step; a project with no TypeScript build step of its own will not run this client as-is.

What I got wrong on the way

My first concurrency test looked like a second strike against the new engine. I fired 50 parallel findUnique calls with Promise.all and the new client took 14-17 ms against the old engine's 3.5-5 ms — three to four times slower, the opposite of the headline number, and I nearly wrote that up as "concurrency regression."

Then I widened the test to 300 parallel calls over three trials instead of one batch of 50. The first trial on the new engine was slow, 56 ms. The second and third were 20.2 ms each — statistically identical to the old engine's 20.2-27 ms range on the same test. What I'd actually measured the first time was a one-off warm-up cost on the very first call of a given query shape through the WASM compiler, not a standing concurrency penalty. A single small batch with no repetition was the wrong instrument for the question I was asking.

What it costs on cold start

This is where the serverless pitch behind this whole rewrite runs into trouble. I split require(), client construction, $connect(), and the first query into separate timings, three runs each.

The new client is about 3.4 times slower from process start to a usable connection, almost a mirror image of the 3.1x it gains back on repeated queries. Removing the Rust binary is specifically pitched as better for serverless and edge runtimes, where cold start is the metric that matters most, and on this measurement it's worse there, not better. A function that serves one request per invocation never gets to the warm, repeated-query phase where the new engine wins.

Run it yourself

// bench.js — run once against each client, three times each const dbFile = './prisma/dev.db'; const t0 = process.hrtime.bigint(); await prisma.$connect(); const t1 = process.hrtime.bigint(); console.log('connect_ms', Number(t1 - t0) / 1e6); const N = 2000; const tQ0 = process.hrtime.bigint(); for (let i = 0; i < N; i++) { await prisma.user.findUnique({ where: { email: `u${i}@test.com` } }); } const tQ1 = process.hrtime.bigint(); console.log('query_ms_for', N, Number(tQ1 - tQ0) / 1e6); 

For the Rust engine: npm i prisma@6 @prisma/client@6, a plain datasource db { provider = "sqlite" url = "file:./dev.db" }, then node bench.js.

For the Rust-free engine: npm i prisma@7.10.1 @prisma/client@7.10.1 @prisma/adapter-better-sqlite3@7.10.1 better-sqlite3, drop url from the datasource block, add a prisma.config.ts, generate with provider = "prisma-client", and run with node --experimental-strip-types bench.js after constructing the client as new PrismaClient({ adapter: new PrismaBetterSqlite3({ url: dbFile }) }).

For node_modules size: du -sb node_modules in each project, before you install anything else.

A process that stays up between requests only pays that 236ms once, then keeps the 3x read speed-up for every query after. A function that gets a fresh container on most invocations pays it almost every time and rarely stays warm long enough to earn the 3x back. Which bucket a given deployment falls into isn't something the Prisma changelog can tell you, so it's worth timing $connect() to first query on the actual driver adapter for your actual database, not mine on SQLite, before moving anything that scales to zero onto 7.10.1.