🚀 The Solution for Slow Prisma

Fix Slow Prisma Queries
Make Your API 2–7× Faster (Up to 53.5×)

Is Prisma slow? You're not alone. Love Prisma's DX but need better performance? Speed up slow Prisma queries by 2–7× (up to 53.5× on SQLite relation filters) without changing any existing queries.

Speed Up Prisma Now See How It Works
Faster Prisma Reads
No Query Changes
Production-Ready
137 E2E Tests
Fix slow Prisma in one line 
import { PrismaClient, Prisma } from '@prisma/client'
import { speedExtension, convertDMMFToModels } from 'prisma-sql'
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL)
const models = convertDMMFToModels(Prisma.dmmf.datamodel)

const prisma = new PrismaClient().$extends(
  speedExtension({ postgres: sql, models })
)

const users = await prisma.user.findMany({
  where: { status: 'ACTIVE' },
  include: { posts: true }
})
2–7×
Faster Prisma Reads
Typical speedup
0
Query Changes
Keep your existing Prisma calls
137
E2E Tests
Verified solution
100%
Type Safety
Same Prisma API

Why Is Prisma Slow?

Understanding Prisma's evolution and performance characteristics helps explain why this extension exists.

The Prisma Journey: DX First, Performance Matters at Scale

🎯 2019: The Birth of Modern Prisma

Prisma 2 launched in 2019, changing the TypeScript ORM landscape with type-safe database access and generated types from your schema. Prisma introduced an engine-based architecture to translate queries, validate them, and provide strong guarantees that were hard to achieve with traditional JavaScript ORMs.

⚡ 2020–2022: Rapid Growth & Feature Expansion

Prisma added powerful features like nested writes, transactions, and middleware. The feature set expanded, but every query still paid an architectural cost: queries are represented, validated, executed, and results are shaped to match the Prisma API.

📊 2023: Overhead Becomes Noticeable at Scale

As more teams deployed Prisma in high-traffic workloads, the fixed per-query overhead became measurable. This is most visible on read-heavy endpoints, analytics, aggregations, and large result sets. The overhead is not a bug; it's the cost of Prisma’s guarantees and API behavior.

🚀 2024–2025: Prisma Performance Work Continues

Prisma shipped major updates focused on performance and engine changes. Even with improvements, there is still an unavoidable cost to parsing, validating, planning, and shaping results compared to executing raw SQL directly.

🎯 2026: prisma-sql Extension Released

This extension focuses on read performance. It bypasses Prisma’s read execution path for findMany, findFirst, findUnique, count, aggregate, and groupBy, while keeping Prisma for writes, migrations, schema management, and type generation. Validate compatibility with your Prisma version before rollout.

💡 Why This Extension Exists

Prisma made the right architectural choices for its goals: type safety, developer experience, and cross-database behavior. But those choices create overhead that's noticeable at scale. This extension doesn't replace Prisma—it optimizes reads for teams that want Prisma's DX plus faster execution where it matters.

Query Translation Layer

Prisma translates your query inputs into database-specific SQL. This enables cross-database behavior and Prisma's API semantics, but adds processing time before the database sees the SQL.

Validation & Type Guarantees

Prisma validates queries against the schema and enforces API-level guarantees. These safeguards prevent classes of bugs, but they also add overhead to each query.

Result Shaping

Results are shaped to match Prisma's API behavior. This is great for DX and consistency, but it adds latency, especially on large result sets and complex includes.

This extension complements Prisma by offering a faster path for read queries. You keep everything you love about Prisma while getting 2–7× faster reads in typical cases (and up to 53.5× in SQLite relation filters) when performance matters.

How Much Faster? Real Benchmarks

Comprehensive comparison across Prisma v6, v7, Drizzle ORM, and Prisma-SQL

Benchmark environment: MacBook Pro M1 • PostgreSQL 15 • SQLite 3.43 • 137 test cases per database

PostgreSQL

Average across 57 test cases

Prisma v6
2.10ms
Prisma v7
1.95ms
1.08× faster
Drizzle ORM
1.40ms
1.50× faster
Prisma-SQL ⚡
0.90ms
2.34× faster
6.3×
Distinct Queries
vs Prisma v6
5.5×
Relation Filters
vs Prisma v6 (none)

SQLite

Average across 56 test cases

Prisma v6
5.48ms
Prisma v7
4.12ms
1.33× faster
Drizzle ORM
2.11ms
2.60× faster
Prisma-SQL ⚡
0.73ms
7.50× faster
12.6×
Simple Queries
vs Prisma v6
69.7×
Relation Filters
vs Prisma v6 (none)

Benchmarks based on 137 E2E tests per database. Prisma v6.16.3, Prisma v7.2.0, Drizzle ORM latest. View complete benchmark data →

Detailed Benchmark Results

Statistical comparison with Welch's t-test and a 1ms practical significance threshold

These results reflect runtime mode, where queries are converted to SQL on each request. In prerendered mode, SQL is generated at build time — runtime executes raw parameterized queries with zero conversion overhead.

PostgreSQL Prisma v6

Avg 2.07x vs Prisma Avg 1.68x vs Drizzle 28/95 significant wins 65 within noise floor
Mar 7, 2026
Test Prisma prisma-sql Drizzle Speedup Sig. CV% n
findMany basic 0.536ms ±0.016 0.272ms ±0.043 1.37ms ~1.00x ≈ 57.0% 50
findMany where = 0.596ms ±0.046 0.354ms ±0.022 0.442ms ~1.00x ≈ 22.3% 50
findMany where >= 16.48ms ±0.251 4.89ms ±0.382 6.48ms 3.37x 1.33x D *** 28.2% 50
findMany where IN 0.609ms ±0.034 0.325ms ±0.016 0.436ms ~1.00x ≈ 17.5% 50
findMany where null 0.254ms ±0.0094 0.122ms ±0.0030 0.167ms ~1.00x ≈ 8.7% 50
findMany ILIKE 0.290ms ±0.043 0.231ms ±0.0083 0.296ms ~1.00x ≈ 13.2% 50
findMany AND 2.77ms ±0.076 1.00ms ±0.109 2.12ms 2.77x 2.12x D *** 39.3% 50
findMany OR 14.10ms ±0.361 4.05ms ±0.388 6.96ms 3.48x 1.72x D *** 34.6% 50
findMany NOT 0.631ms ±0.042 0.363ms ±0.026 0.454ms ~1.00x ≈ 26.3% 50
findMany orderBy 2.11ms ±0.080 0.893ms ±0.081 1.12ms 2.36x 1.25x D *** 32.7% 50
findMany pagination 0.248ms ±0.013 0.217ms ±0.0089 0.228ms ~1.00x ≈ 14.9% 50
findMany select 0.309ms ±0.058 0.101ms ±0.0064 0.116ms ~1.00x ≈ 22.6% 50
findMany relation some 0.910ms ±0.030 0.450ms ±0.016 — ~1.00x ≈ 12.6% 50
findMany relation every 0.710ms ±0.026 0.491ms ±0.012 — ~1.00x ≈ 8.7% 50
findMany relation none 31.70ms ±4.16 7.65ms ±0.483 — 4.15x *** 22.8% 50
findMany nested relation 0.952ms ±0.088 1.06ms ±0.138 — ~1.00x ≈ 46.7% 50
findMany complex 1.12ms ±0.029 0.520ms ±0.017 0.651ms ~1.00x ≈ 11.7% 50
findFirst 0.240ms ±0.013 0.195ms ±0.014 0.262ms ~1.00x ≈ 25.0% 50
findFirst skip 0.284ms ±0.018 0.176ms ±0.0080 0.219ms ~1.00x ≈ 16.7% 50
findUnique id 0.220ms ±0.016 0.163ms ±0.028 0.167ms ~1.00x ≈ 61.9% 50
findUnique email 0.180ms ±0.012 0.104ms ±0.0075 0.133ms ~1.00x ≈ 26.0% 50
count 0.124ms ±0.026 0.048ms ±0.0019 0.063ms ~1.00x ≈ 13.8% 50
count where 0.435ms ±0.0094 0.265ms ±0.011 0.273ms ~1.00x ≈ 15.4% 50
aggregate count 0.230ms ±0.0069 0.151ms ±0.0028 — ~1.00x ≈ 6.5% 50
aggregate sum/avg 0.355ms ±0.018 0.263ms ±0.013 — ~1.00x ≈ 18.0% 50
aggregate where 0.438ms ±0.010 0.275ms ±0.014 — ~1.00x ≈ 18.9% 50
aggregate min/max 0.344ms ±0.015 0.289ms ±0.031 — ~1.00x ≈ 38.6% 50
aggregate complete 0.420ms ±0.014 0.317ms ±0.033 — ~1.00x ≈ 37.4% 50
groupBy 0.447ms ±0.015 0.339ms ±0.011 — ~1.00x ≈ 11.4% 50
groupBy count 0.461ms ±0.011 0.381ms ±0.014 — ~1.00x ≈ 13.0% 50
groupBy multi 0.573ms ±0.019 0.431ms ±0.0097 — ~1.00x ≈ 8.1% 50
groupBy having 0.585ms ±0.034 0.473ms ±0.011 — ~1.00x ≈ 8.6% 50
groupBy + where 0.596ms ±0.031 0.431ms ±0.038 — ~1.00x ≈ 31.5% 50
_count via include 0.702ms ±0.023 0.704ms ±0.040 — ~1.00x ≈ 20.4% 50
_count via include + relations 1.86ms ±0.108 1.48ms ±0.072 — ~1.00x ≈ 17.7% 50
groupBy aggregates 0.576ms ±0.027 0.578ms ±0.062 — ~1.00x ≈ 38.8% 50
groupBy min/max 0.571ms ±0.048 0.589ms ±0.073 — ~1.00x ≈ 44.8% 50
include list + nested to-one 1.77ms ±0.103 0.460ms ±0.034 — 3.86x *** 26.9% 50
include list + nullable to-one 2.77ms ±0.100 2.14ms ±0.170 — ~1.00x ≈ 28.6% 50
include posts 2.86ms ±0.201 1.07ms ±0.069 6.00ms 2.66x 5.58x D *** 23.2% 50
include profile 0.533ms ±0.027 0.489ms ±0.030 0.549ms ~1.00x ≈ 21.8% 50
include 3 levels 1.99ms ±0.100 1.70ms ±0.190 1.96ms ~1.00x ≈ 40.2% 50
include 4 levels 2.45ms ±0.103 1.25ms ±0.030 3.81ms 1.96x 3.05x D *** 8.8% 50
include + where 2.61ms ±0.100 0.948ms ±0.100 4.59ms 2.76x 4.84x D *** 38.1% 50
include + select nested 2.27ms ±0.124 1.34ms ±0.106 3.71ms ~1.00x ≈ 28.5% 50
findMany startsWith 0.282ms ±0.031 0.185ms ±0.030 0.230ms ~1.00x ≈ 58.7% 50
findMany endsWith 0.640ms ±0.057 0.296ms ±0.049 0.470ms ~1.00x ≈ 59.0% 50
findMany NOT contains 0.661ms ±0.024 0.329ms ±0.050 0.413ms ~1.00x ≈ 55.1% 50
findMany LIKE 0.257ms ±0.026 0.181ms ±0.0061 0.208ms ~1.00x ≈ 12.3% 50
findMany < 27.72ms ±2.31 6.64ms ±0.325 11.44ms 4.18x 1.72x D *** 17.7% 50
findMany <= 28.41ms ±0.842 6.96ms ±0.419 11.50ms 4.08x 1.65x D *** 21.7% 50
findMany > 18.50ms ±3.09 4.00ms ±0.196 6.24ms 4.63x 1.56x D *** 17.7% 50
findMany NOT IN 0.593ms ±0.032 0.285ms ±0.012 0.351ms ~1.00x ≈ 15.4% 50
findMany isNot null 0.580ms ±0.017 0.194ms ±0.0036 0.294ms ~1.00x ≈ 6.6% 50
orderBy multi-field 5.19ms ±0.480 3.14ms ±1.04 1.51ms 1.66x 0.48x D ** 119.3% 50
orderBy relation to-one 2.38ms ±0.066 1.72ms ±0.131 — ~1.00x ≈ 27.5% 50
orderBy relation + scalar 2.22ms ±0.039 1.69ms ±0.093 — ~1.00x ≈ 19.9% 50
orderBy nullable relation 1.94ms ±0.056 1.30ms ±0.058 — ~1.00x ≈ 16.0% 50
orderBy deep relation 2.45ms ±0.070 1.73ms ±0.040 — ~1.00x ≈ 8.3% 50
orderBy deep relation + scalar 3.38ms ±0.250 2.07ms ±0.053 — 1.63x *** 9.2% 50
distinct status 11.52ms ±2.73 1.38ms ±0.137 — 8.33x *** 35.8% 50
distinct multi 14.12ms ±0.732 2.60ms ±0.054 — 5.43x *** 7.5% 50
cursor composite tuple 1.97ms ±0.081 1.50ms ±0.081 — ~1.00x ≈ 19.4% 50
cursor composite desc 2.91ms ±1.29 1.66ms ±0.135 — 1.75x ns 29.4% 50
cursor prefix of orderBy 2.03ms ±0.074 1.38ms ±0.040 — ~1.00x ≈ 10.4% 50
select + include 1.19ms ±0.081 0.254ms ±0.015 0.415ms ~1.00x ≈ 21.8% 50
_count relation 0.898ms ±0.070 0.648ms ±0.034 — ~1.00x ≈ 19.2% 50
_count multi-relation 0.244ms ±0.014 0.172ms ±0.0080 — ~1.00x ≈ 17.1% 50
_count inside include 1.37ms ±0.055 1.35ms ±0.130 — ~1.00x ≈ 34.7% 50
_count inside nested select 1.91ms ±0.049 1.43ms ±0.057 — ~1.00x ≈ 14.4% 50
_count deep include 1.92ms ±0.040 1.40ms ±0.044 — ~1.00x ≈ 11.4% 50
ILIKE special chars 0.511ms ±0.262 0.177ms ±0.0064 — ~1.00x ≈ 12.8% 50
LIKE case sensitive 0.213ms ±0.012 0.164ms ±0.0053 — ~1.00x ≈ 11.5% 50
findMany Date range 0.368ms ±0.018 0.517ms ±0.019 0.833ms ~1.00x ≈ 13.6% 50
count Date range 0.508ms ±0.016 0.817ms ±0.295 0.438ms ~1.00x ≈ 130.1% 50
findMany Date gte 0.387ms ±0.032 0.184ms ±0.0025 0.242ms ~1.00x ≈ 5.0% 50
depth-1 low-fan 0.502ms ±0.045 0.666ms ±0.303 — ~1.00x ≈ 164.1% 50
depth-1 mid-fan 3.02ms ±0.187 1.26ms ±0.148 — 2.40x *** 42.3% 50
depth-1 high-fan 3.49ms ±0.138 1.01ms ±0.066 — 3.44x *** 23.3% 50
depth-1 wide 6.05ms ±1.65 1.51ms ±0.104 — 4.00x *** 24.8% 50
depth-1 unbound 43.36ms ±2.79 8.43ms ±0.343 — 5.14x *** 14.7% 50
depth-2 3.79ms ±0.176 2.60ms ±0.150 — 1.45x *** 20.8% 50
depth-2 paginated Project→tasks 1.52ms ±0.067 1.66ms ±0.174 — ~1.00x ≈ 37.9% 50
depth-2 high-fan 2.14ms ±0.044 1.21ms ±0.060 — ~1.00x ≈ 18.1% 50
depth-2 wide 5.24ms ±0.307 1.92ms ±0.179 — 2.73x *** 33.8% 50
depth-2 unbound 78.61ms ±23.12 13.71ms ±0.633 — 5.74x *** 7.5% 10
depth-3 unbound 16.38ms ±1.37 6.59ms ±0.241 — 2.49x *** 13.2% 50
depth-3 paginated 2.04ms ±0.117 2.19ms ±0.542 — ~1.00x ≈ 89.3% 50
depth-4 unbound 9.62ms ±0.235 3.27ms ±0.186 — 2.94x *** 20.5% 50
depth-4 paginated 2.56ms ±0.095 1.78ms ±0.230 — ~1.00x ≈ 46.4% 50
findFirst depth-2 3.53ms ±0.968 1.52ms ±0.134 — 2.33x *** 32.0% 50
findUnique depth-2 Project→tasks→comment 2.77ms ±0.164 2.94ms ±0.761 — ~1.00x ≈ 93.5% 50
complex nested select 5.70ms ±0.317 4.49ms ±0.196 — 1.27x *** 15.7% 50
ultra deep query 7.62ms ±0.180 11.97ms ±5.92 — 0.64x ns 178.5% 50
transaction: (3 operations) 2.91ms ±0.054 1.23ms ±0.069 — 2.37x *** 20.4% 50
*** p < 0.001 ** p < 0.01 *  p < 0.05 ns not significant ≈ within 1ms noise floor ± 95% CI CV% > 15% = high variance
Runtime mode benchmarked. Prerendered mode skips query-to-SQL conversion entirely at runtime — expect lower latency than shown here, especially for complex queries where conversion cost is proportionally higher.
View raw benchmark data on GitHub →
✓ Validated

How do we ensure correctness?

Every query is validated against Prisma with 137 end-to-end tests across PostgreSQL and SQLite

View Testing Methodology →

How It Optimizes Prisma

Bypass Prisma's read execution path while keeping Prisma's API and types

1

Intercept Prisma Queries

Extension catches read operations (findMany, findFirst, findUnique, count, aggregate, groupBy) before they execute

2

Generate Optimized SQL

Convert Prisma queries into fast, parameterized SQL with optimized JOINs

3

Execute Directly

Run queries through postgres.js or better-sqlite3, bypassing Prisma read overhead

4

Return Compatible Results

Results match Prisma's expected shape. Types, IntelliSense, and existing query code remain unchanged

const users = await prisma.user.findMany({
  where: { status: 'ACTIVE' },
  include: { posts: true }
})

// Direct SQL execution for reads
// Benchmarked around ~1.00ms on this workload
// Same Prisma query code
🔒 Verified Secure

How do we prevent SQL injection?

Multi-layer validation with parameter binding, schema-based field checks, and 137 security tests (current suite)

View Security Details →

Why Choose This Prisma Extension?

Get raw SQL execution speed for reads while keeping Prisma's developer experience

Instant Prisma Speedup

One-time setup accelerates Prisma reads. No refactoring, no migration, no downtime.

Keep Your Prisma Types

Full TypeScript support maintained. Type inference, autocomplete, and compile-time safety preserved while accelerating reads.

Production-Tested Solution

137 E2E tests validate compatibility with recent Prisma versions. Used to accelerate Prisma reads in production apps.

Multiple Database Support

Optimize Prisma reads on PostgreSQL (including Neon, Supabase) and SQLite.

Pre-Compiled Option

Optional generator creates build-time SQL, reducing overhead to microseconds for your hottest queries.

Serverless Ready (Node Runtimes)

Works in serverless Node runtimes. Edge runtime support depends on runtime constraints and the driver you use.

When Prisma Performance Matters Most

Common scenarios where this extension makes a real difference

📊 Analytics & Reporting

Prisma aggregations and groupBy operations benefit significantly from direct SQL execution

  • 5× faster groupBy accelerates reports
  • Faster aggregate queries
  • Real-time metrics with lower latency

🚀 High-Traffic APIs

Per-query overhead compounds under load, especially on read-heavy endpoints

  • Lower API response times
  • Handle more requests per instance
  • Reduce infrastructure costs

☁️ Serverless Functions

Every millisecond matters in serverless: reduce read latency where it counts

  • Better p95/p99 on reads
  • Lower costs through faster reads
  • Faster reads without refactors

📱 Mobile Backends

Users notice latency: faster reads improve perceived UX immediately

  • Faster feed loading
  • Faster pagination
  • More responsive interactions

Optimize Prisma in 3 Steps

Accelerate Prisma reads in under 60 seconds

① Install the Prisma Extension 

# PostgreSQL
npm install prisma-sql postgres

# SQLite
npm install prisma-sql better-sqlite3

② Add Extension to Prisma Client 

import { PrismaClient, Prisma } from '@prisma/client'
import { speedExtension, convertDMMFToModels } from 'prisma-sql'
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL)
const models = convertDMMFToModels(Prisma.dmmf.datamodel)

const prisma = new PrismaClient().$extends(
  speedExtension({ postgres: sql, models })
)

③ Use Prisma Normally 

const users = await prisma.user.findMany({
  where: { status: 'ACTIVE' },
  include: { posts: true }
})

Prisma Performance FAQ

Common questions about optimizing Prisma reads

Why does Prisma have overhead?

Prisma adds overhead because it implements API guarantees like schema-based validation, consistent query behavior, and result shaping. Those layers provide a great developer experience but cost time compared to executing raw SQL directly.

How do I optimize Prisma queries?

Optimize read-heavy Prisma workloads by adding this extension. It executes read operations via direct SQL using postgres.js or better-sqlite3 while keeping Prisma's API and types. Setup is a small initialization change and does not require refactoring your existing queries.

Is Prisma slower than raw SQL?

For many read workloads, yes. There is architectural overhead compared to raw SQL execution. This extension aims to keep Prisma's DX while reducing read latency by executing SQL directly.

Can I speed up Prisma without changing existing queries?

Yes. Add the extension once during Prisma Client initialization and keep your existing Prisma query code unchanged. Read operations run faster while your Prisma API, types, and schema remain the same.

Does this work in production?

Yes. It is validated with 137 E2E tests and designed to be used in production. Always verify compatibility with your Prisma version and run your own regression tests before rollout.

What causes slower Prisma aggregations?

Aggregations and groupBy often amplify fixed overhead (query processing and result shaping) and can involve larger intermediate result sets. This extension optimizes those reads by generating SQL directly, which typically reduces latency on aggregation-heavy endpoints.

Ready to Speed Up Prisma?

Join developers optimizing Prisma reads: 2–7× faster (up to 53.5×)

Install Prisma-SQL View on GitHub