# Prisma 8 Is ~90% As Fast as Raw PG

URL: https://www.prisma.io/blog/prisma-next-performance-benchmark
Published: 2026-06-11
Authors: Serhii Tatarintsev
Tags: orm, education
Series: Prisma 8
Description: Prisma 8 performance benchmarks achieves ~90% of the raw pg driver's peak throughput, holds latency low under load, and ships as a 148.5 KB gzipped bundle for serverless and edge workloads.

> *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](https://pris.ly/pn-series), 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](https://www.prisma.io/docs/orm) 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.

## How we ran the benchmark [#how-we-ran-the-benchmark]

The benchmark is a fork of the open-source [`drizzle-team/drizzle-benchmarks`](https://github.com/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.](https://pris.ly/pn-benchmarks)

## Peak throughput: Prisma 8 keeps climbing [#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.

![Throughput over the load test: Prisma 7 flattens out just under 8,000 req/s while Prisma 8 and pg keep climbing](https://www.prisma.io/blog/prisma-next-performance-benchmark/imgs/throughput-ramp.png)

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:

![Peak sustained throughput: pg \~14,350 req/s, Prisma 8 \~12,534 (87% of pg), Prisma 7 \~8,260 (58% of pg)](https://www.prisma.io/blog/prisma-next-performance-benchmark/imgs/peak-throughput.svg)

| Setup             | Peak throughput (req/s) | vs Prisma 7 | % of `pg` |
| ----------------- | ----------------------- | ----------- | --------- |
| `pg` (raw driver) | \~14,350                | —           | 100%      |
| Prisma 8          | \~12,500                | +52%        | 87%       |
| Prisma 7          | \~8,300                 | —           | 58%       |

## Latency at the same load [#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):

| Setup             | Avg latency | p95 latency | p99 latency |
| ----------------- | ----------- | ----------- | ----------- |
| `pg` (raw driver) | 0.7 ms      | 1.9 ms      | 4.3 ms      |
| Prisma 8          | 1.2 ms      | 4.4 ms      | 8.9 ms      |
| Prisma 7          | 8.1 ms      | 41.8 ms     | 116.7 ms    |

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.

![p95 latency over the load test: Prisma 8 stays low well up the range and pg stays lowest, while Prisma 7 rises earlier as it nears its peak](https://www.prisma.io/blog/prisma-next-performance-benchmark/imgs/latency-over-time.svg)

## A smaller bundle, especially for serverless [#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 [#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 [#limitations-and-whats-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](https://pris.ly/pn-benchmarks), so you can run it yourself and tell us where we're wrong. We'll keep testing more workloads and tuning Prisma 8's performance.

## Try Prisma 8 today [#try-prisma-8-today]

There are two ways to [get started](https://www.prisma.io/docs/prisma-orm/quickstart/postgresql). To spin up a complete template app, scaffold one with:

```shell
bunx create-prisma@latest
```

This sets you up with a [Prisma Postgres](https://www.prisma.io/postgres) database and can deploy the app to [Prisma Compute](https://www.prisma.io/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:

```shell
bunx prisma@latest orm init
```

To learn more, start with the [announcement blog post](https://pris.ly/pn-ea). Star and watch [prisma/prisma](https://github.com/prisma/orm) on GitHub to follow what ships next, and if you hit a snag, start a thread in [`#prisma-next` on our Discord](https://pris.ly/discord).