Prisma 8 Is ~90% As Fast as Raw PG

Editor's note: Prisma 8 was developed under the working name Prisma Next. This post has been updated to use the final name.

Every ORM does work on every query: it turns your query into SQL, sends it, and turns the rows that come back into objects. That work has a cost, and in Prisma 7 it sits deep in the architecture, so reducing it meant rebuilding the layers underneath.

That rebuild is Prisma 8, the new foundation for Prisma ORM. It's written in TypeScript end to end and runs on a much lighter core, while keeping the same model-first, type-safe workflow you already use.

To see where it stands, we ran the same Postgres workload through three setups: Prisma 7, Prisma 8, and the raw pg driver. We pushed traffic up until each one reached its limit.

• Prisma 7 tops out around 8,300 requests/second, and Prisma 8 keeps scaling to about 12,500, roughly 50% more.
• At 6,000 to 7,000 requests/second, a level both can serve, Prisma 8's p95 latency stays around 4 ms while Prisma 7's has already climbed past 40 ms.
• Prisma 8 reaches about 87% of the raw pg driver's peak, while Prisma 7 reaches about 58%.

Its bundle size gzipped is about 148.5 KB gzipped, compared to 1.32 MB for Prisma 7, also about 9× smaller to ship, which matters for serverless and edge deployments where bundle size drives cold starts. We look at that below.

One note before the numbers: Prisma 7 is still the version to use in production today. The Prisma 8 Release Candidate is available, and once it's Generally Available you'll be able to run it in production too.

How we ran the benchmark

The benchmark is a fork of the open-source drizzle-team/drizzle-benchmarks suite. We kept its setup and workload and added Prisma 8 alongside the existing setups, so the methodology comes from outside Prisma rather than from us.

It points a load generator at a small HTTP service backed by a single Postgres database, runs the identical workload against each setup on the same machine, and ramps traffic from light all the way up to its limit while recording throughput and latency at each step.

The raw pg driver is our baseline: the fastest this machine can talk to the database, with none of an ORM's higher-level work, since you write the SQL and handle the rows yourself. Prisma 8 isn't trying to beat it. The question is how much overhead is left once Prisma's workflow sits on top.

Here's our benchmark fork with setup, raw data, versions, and methodology.

Peak throughput: Prisma 8 keeps climbing

This is the main result. As traffic rises, all three lines climb together at first; then Prisma 7 flattens out, while Prisma 8 and pg keep climbing for thousands more requests per second.

That flat line is the overhead the new foundation was built to reduce. The peak each setup sustains, measured as the average of its busiest 10% of the run, lands here:

Latency at the same load

Peak throughput shows how far each setup scales, and latency shows how it feels along the way. To compare fairly we look at the same traffic going into each, rather than a fully loaded Prisma 7 against a Prisma 8 with room to spare.

Below about 5,000 requests/second all three sit within a few milliseconds of each other, and the gap opens as traffic climbs toward the top of Prisma 7's range. Here's 6,000 to 7,000 requests/second, where all three keep up but the differences start to show (p95 and p99 are the slowest 5% and 1% of requests):

Prisma 8 stays within a few milliseconds of the raw driver here, and that holds well past the load where Prisma 7 hits its ceiling. Every setup eventually slows down as it approaches its own limit; Prisma 8 simply reaches that point much later.

Tracking p95 latency across the run shows the same split: Prisma 7's line turns upward early and climbs steeply as it nears its limit, reaching roughly 400 milliseconds, while the Prisma 8 and pg lines stay flat and low far longer.

A smaller bundle, especially for serverless

The lighter core makes Prisma 8 far smaller to ship: about 148.5 KB gzipped, compared to 1.32 MB for Prisma 7, roughly 9× smaller.

This matters most for serverless and edge. A smaller bundle means faster cold starts, smaller deployment artifacts, and more headroom under the size limits that platforms like Cloudflare Workers and Vercel enforce. If you've ever fought Prisma's footprint in an edge or serverless function, this is the part of Prisma 8 to try first.

What this means for your app

Benchmarks are direction, not a promise. A few things to keep in mind:

• Less work per query is what raises the ceiling and steadies latency.
• Most apps run well below these peaks, where all three setups are close. The gap matters under spikes.
• Your schema, indexes, and query shape usually affect performance more than the ORM does.
• If you ruled Prisma out on performance, it's worth another look.

Limitations and what's next

A few caveats. This is one benchmark, on one workload and one machine, so results will shift with different queries, data volumes, and hardware.

We've shared our benchmark repo, so you can run it yourself and tell us where we're wrong. We'll keep testing more workloads and tuning as Prisma 8 moves toward general availability.

Try Prisma 8 today

There are two ways to get started. To spin up a complete template app, scaffold one with:

bunx create-prisma@next

This sets you up with a Prisma Postgres database and can deploy the app to Prisma Compute, our serverless runtime for Prisma apps, so you can see the bundle-size and cold-start benefits above end to end.

To add Prisma 8 to an existing app, run:

bunx prisma-next@latest init

To learn more, start with the announcement blog post. Star and watch prisma/prisma-next on GitHub to follow what ships next, and if you hit a snag, start a thread in #prisma-next on our Discord.