Drizzle 1.0 RC edges Prisma 8 RC in PostgreSQL benchmark, but Prisma 7 wins deep pagination

An independent benchmark published on dev.to in mid-October 2026 ran four TypeScript data-access clients against the same PostgreSQL 17 database: Drizzle 0.45.4, the Drizzle 1.0.0-rc.4 release candidate, Prisma 7.10.1 and the Prisma 8.0.0-rc.18 release candidate. The original write-up, which its author says will carry any updates, lives on fabwaseem.com.

The timing is notable because both projects sit between major versions. According to the author, Drizzle 1.0 is still on the npm rc dist-tag while 0.45.4 remains latest, whereas Prisma 8's release candidate is already what a plain npm install pulls in. Numbers covering both the stable and upcoming lines of each tool are therefore unusually current.

What was measured

The tests ran locally: PostgreSQL 17.11 on the same machine as the client (an 8 vCPU Xeon with 15 GB of RAM), Node.js 24.22.0, and a dataset of 1,000 users and 10,000 posts with an index on Post.authorId. Each case did 200 warm-up calls followed by 2,000 timed calls, repeated three times per client with inserted rows deleted between runs; the reported figures are medians. The author also tested Drizzle 1.0 with its jit option switched on.

The headline numbers

On simple operations the four clients were nearly indistinguishable. Primary-key lookups landed between 0.121 ms (Drizzle 1.0 rc.4) and 0.195 ms (Prisma 8 rc.18), a spread the author says vanishes over a real network. Single-row inserts looked similar, from 0.139 ms for Drizzle 1.0 to 0.208 ms for Prisma 8.

The first page of a nested read — 20 users with their posts — widened the gap: Drizzle 1.0 rc.4 returned it in 0.561 ms, Drizzle 0.45.4 and Prisma 7.10.1 clustered near 0.72–0.73 ms, and Prisma 8 rc.18 took 1.185 ms.

Deep pagination then reversed the order. At OFFSET 960, Prisma 7.10.1 was fastest at 0.749 ms, Drizzle 0.45.4 took 4.650 ms, Drizzle 1.0 rc.4 5.164 ms and Prisma 8 rc.18 8.060 ms. The author summarises that common pattern as a 6–19x difference and blames the shape of the generated SQL, not the ORM's own overhead.

Two side findings stand out. Drizzle 1.0's jit flag, documented as compiling row mappers just in time, made no measurable difference here, because mapping 20 rows is not where the time goes. And resident memory after the run ranged from 251 MB (Drizzle 0.45.4) to 404 MB (Prisma 8), with the others between 289 and 296 MB.

Why deep pagination flips the result

Drizzle and Prisma 8 load relations inside a single SQL statement that builds a JSON subquery for each parent row. PostgreSQL applies OFFSET last, so the database constructs the JSON for every skipped row and then throws it away; at OFFSET 960 the author's EXPLAIN ANALYZE output showed the posts subquery running 980 times to serve 20 users. Prisma 7 instead defaults to issuing two queries, which touch only the rows actually needed, which is why its deep-page timing stays flat. The author's conclusion is that the remedy lies in the query pattern, not the library: two-query loading or keyset pagination avoids the cost entirely.

Choosing between them

On deployment weight, the benchmark reports Drizzle installing at 21–30 MB across 18 packages with a bundled cold start near 35 ms, Prisma 7 at 329 MB with roughly 100 ms cold start, and Prisma 8 at 130 MB but about 370 ms to cold-start in this test.

The broader trade-off is stylistic. Drizzle defines tables in TypeScript and offers a typed SQL builder with no code-generation step, while Prisma models data in its own schema language and generates a client — Prisma 7 via schema.prisma and prisma generate, Prisma 8 moving to contract.prisma and a chained query API. The author's advice: choose Drizzle if you think in SQL, deploy to serverless or edge runtimes, and want the smallest footprint; choose Prisma 7 if you want its guided workflow, generated client and Prisma Migrate; and wait for general availability before moving production to either release candidate.

Why it matters

Drizzle and Prisma are changing major versions at the same time, and this is a rare same-hardware, same-data comparison of all four lines. It also reframes the performance argument: the biggest gap in the results comes not from ORM overhead but from how each tool compiles nested reads into SQL — and paginated lists with relations are a pattern most applications run constantly. Teams choosing a data layer, or deciding whether to upgrade, get current evidence on where each option is fast, where it is not, and which differences are architectural rather than tunable.