Corrigez les requêtes Prisma lentes grâce à l’exécution SQL directe

Vous aimez le DX de Prisma mais avez besoin d’un overhead de lecture plus faible sur les formes de requête prises en charge ? Le JSON de benchmark actuel montre des accélérations moyennes sur Prisma v6, v7 et v8 pour les lectures PostgreSQL et SQLite prises en charge ; les résultats varient selon la forme de requête.

Accélérer Prisma maintenant

Lectures prises en charge plus rapides
Aucun changement de requête
JSON de benchmark actuel
PostgreSQL & SQLite

Votre appel Prismauser.findMany

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

SQL exécuté par prisma-sql

SELECT user_t.id, user_t.email, user_t.status,  COALESCE((    SELECT COALESCE(json_agg(json_build_object(      'id', posts_0.id,      'title', posts_0.title,      'authorId', posts_0."authorId"    )), '[]'::json)    FROM "public"."Post" posts_0    WHERE posts_0."authorId" = user_t.id  ), '[]'::json) AS postsFROM "public"."User" user_tWHERE user_t.status = $1

params ["ACTIVE"]1 instruction

SELECT user_t.id, user_t.email, user_t.status,  COALESCE((    SELECT COALESCE(json_group_array(row), json('[]'))    FROM (      SELECT json_object(        'id', posts_0.id,        'title', posts_0.title,        'authorId', posts_0."authorId"      ) AS row      FROM "Post" posts_0      WHERE posts_0."authorId" = user_t.id    ) AS posts_row_1  ), json('[]')) AS postsFROM "User" user_tWHERE user_t.status = ?

params ["ACTIVE"]1 instruction

Sortie de createToSQL pour un schéma à deux modèles, retours à la ligne ajoutés.

Couverture Prisma: v6–v8; Matrice de benchmarks PostgreSQL et SQLite
Changements de requête: 0; Conservez vos appels Prisma existants
Fichiers de benchmark: 6; Prisma v6/v7/v8 × PG/SQLite
Sécurité des types: 100%; Même API Prisma

Pourquoi Prisma est-il lent ?

Comprendre l’évolution de Prisma et ses caractéristiques de performance aide à expliquer pourquoi cette extension existe.

Le parcours de Prisma : le DX d’abord, la performance compte à l’échelle

💡 Pourquoi cette extension existe

Prisma a fait les bons choix architecturaux pour ses objectifs : sécurité des types, expérience développeur et comportement multi-bases. Mais ces choix créent un overhead perceptible à l’échelle. Cette extension ne remplace pas Prisma — elle optimise les lectures pour les équipes qui veulent le DX de Prisma plus une exécution plus rapide là où ça compte.

🎯 2019 : La naissance de Prisma moderne
Prisma 2 a été lancé en 2019, changeant le paysage des ORM TypeScript avec un accès base de données typé et des types générés depuis votre schéma. Prisma a introduit une architecture basée sur un engine pour traduire les requêtes, les valider et fournir des garanties fortes, difficiles à atteindre avec les ORM JavaScript traditionnels.
⚡ 2020–2022 : Croissance rapide et expansion des fonctionnalités
Prisma a ajouté des fonctionnalités puissantes comme les écritures imbriquées, les transactions et le middleware. Le périmètre fonctionnel s’est élargi, mais chaque requête payait toujours un coût architectural : les requêtes sont représentées, validées, exécutées, puis les résultats sont mis en forme pour correspondre à l’API Prisma.
📊 2023 : L’overhead devient visible à l’échelle
À mesure que davantage d’équipes ont déployé Prisma sur des workloads à fort trafic, l’overhead fixe par requête est devenu mesurable. C’est le plus visible sur les endpoints dominés par la lecture, l’analytics, les agrégations et les gros jeux de résultats. Cet overhead n’est pas un bug ; c’est le coût des garanties et du comportement d’API de Prisma.
🚀 2024–2025 : Le travail performance de Prisma continue
Prisma a livré des mises à jour majeures axées sur la performance et des changements d’engine. Même avec des améliorations, il subsiste un coût inévitable pour parser, valider, planifier et mettre en forme les résultats, comparé à l’exécution directe de SQL brut.
🎯 2026 : Sortie de l’extension prisma-sql
Cette extension se concentre sur les performances en lecture. Elle contourne le chemin d’exécution de lecture de Prisma pour findMany, findFirst, findUnique, count, aggregate et groupBy, tout en conservant Prisma pour les écritures, les migrations, la gestion du schéma et la génération de types. Validez la compatibilité avec votre version de Prisma avant déploiement.

Couche de traduction des requêtes

Prisma traduit les entrées de vos requêtes en SQL spécifique à la base de données. Cela permet un comportement multi-bases et la sémantique de l’API Prisma, mais ajoute du temps de traitement avant que la base ne voie le SQL.

Validation et garanties de type

Prisma valide les requêtes contre le schéma et applique des garanties au niveau de l’API. Ces garde-fous évitent certaines classes de bugs, mais ajoutent aussi de l’overhead à chaque requête.

Mise en forme des résultats

Les résultats sont mis en forme pour correspondre au comportement de l’API Prisma. C’est excellent pour le DX et la cohérence, mais cela ajoute de la latence, surtout avec de gros jeux de résultats et des includes complexes.

Cette extension complète Prisma en offrant un chemin plus rapide pour les requêtes de lecture prises en charge. Vous gardez Prisma pour le schéma, les migrations, les écritures et les types générés, tandis que le SQL généré prend en charge certaines lectures critiques via des clients natifs de la base de données.

À quelle vitesse ? Benchmarks réels

Comparaison des derniers JSON de benchmark entre Prisma v6, v7, v8, Drizzle ORM et prisma-sql

PostgreSQL

95 cas de requête par run

Prisma v6 (6.19.3)1.56× vs Drizzle
1.99×
Prisma v6 (6.19.3) : accélération moyenne de 1.99× par rapport à Prisma
95 cas de requête mesurés, moyenne vs Prisma30 sept. 2026
Prisma v7 (7.10.0)1.51× vs Drizzle
1.47×
Prisma v7 (7.10.0) : accélération moyenne de 1.47× par rapport à Prisma
95 cas de requête mesurés, moyenne vs Prisma30 sept. 2026
Prisma v8 (8.1.0-dev.1)1.63× vs Drizzle
1.54×
Prisma v8 (8.1.0-dev.1) : accélération moyenne de 1.54× par rapport à Prisma
95 cas de requête mesurés, moyenne vs Prisma30 sept. 2026

SQLite

84 cas de requête par run

Prisma v6 (6.19.3)1.79× vs Drizzle
4.80×
Prisma v6 (6.19.3) : accélération moyenne de 4.80× par rapport à Prisma
84 cas de requête mesurés, moyenne vs Prisma30 sept. 2026
Prisma v7 (7.10.0)1.84× vs Drizzle
2.29×
Prisma v7 (7.10.0) : accélération moyenne de 2.29× par rapport à Prisma
84 cas de requête mesurés, moyenne vs Prisma30 sept. 2026
Prisma v8 (8.1.0-dev.1)1.63× vs Drizzle
2.10×
Prisma v8 (8.1.0-dev.1) : accélération moyenne de 2.10× par rapport à Prisma
84 cas de requête mesurés, moyenne vs Prisma30 sept. 2026

Généré au build à partir des derniers fichiers benchmark-results/*-latest.json. Les barres partagent une même échelle pour les deux bases de données ; l’ambre marque le meilleur run par base. Les résultats varient selon la forme de requête.Tableau par requête Voir les données complètes du benchmark

Résultats détaillés des benchmarks

Comparaison statistique avec le test t de Welch et un seuil de significativité pratique de 1 ms

Ces résultats reflètent le mode runtime, où les requêtes sont converties en SQL à chaque appel. En mode prérendu, le SQL est généré au build — le runtime exécute des requêtes paramétrées brutes sans aucun coût de conversion.

PostgreSQLPrisma v6 (6.19.3)

Moyenne 1.99x vs PrismaMoyenne 1.56x vs Drizzle35/95 gains significatifs60 dans le seuil de bruit

30 sept. 2026

Test	Prisma	prisma-sql	Drizzle	Accélération	Sig.	CV%	n
findMany basic	0.529ms±0.064	0.231ms±0.234	0.271ms	~1.00x	≈	198.0%	50
findMany where =	0.501ms±0.0069	0.208ms±0.0094	0.347ms	~1.00x	≈	15.6%	50
findMany where >=	16.51ms±0.267	5.67ms±0.338	7.43ms	2.91x1.31x D	***	21.0%	50
findMany where IN	0.657ms±0.142	0.292ms±0.017	0.492ms	~1.00x	≈	20.3%	50
findMany where null	0.280ms±0.020	0.167ms±0.012	0.177ms	~1.00x	≈	25.7%	50
findMany ILIKE	0.297ms±0.0097	0.168ms±0.0089	0.278ms	~1.00x	≈	18.6%	50
findMany AND	2.72ms±0.161	1.11ms±0.111	1.45ms	2.45x1.31x D	***	31.5%	50
findMany OR	13.98ms±0.286	4.69ms±0.221	5.88ms	2.98x1.25x D	***	17.0%	50
findMany NOT	0.639ms±0.013	0.274ms±0.0091	0.478ms	~1.00x	≈	12.2%	50
findMany orderBy	4.50ms±0.219	1.48ms±0.075	1.76ms	3.03x1.18x D	***	18.5%	50
findMany pagination	0.342ms±0.032	0.171ms±0.026	0.295ms	~1.00x	≈	43.2%	50
findMany select	0.294ms±0.0094	0.181ms±0.0072	0.176ms	~1.00x	≈	14.0%	50
findMany relation some	1.69ms±0.098	0.999ms±0.064	—	~1.00x	≈	22.1%	50
findMany relation every	2.17ms±0.096	1.47ms±0.078	—	~1.00x	≈	18.9%	50
findMany relation none	26.02ms±0.517	10.06ms±0.511	—	2.59x	***	18.0%	50
findMany nested relation	1.76ms±0.076	1.24ms±0.060	—	~1.00x	≈	18.0%	50
findMany complex	2.94ms±0.109	1.46ms±0.068	1.73ms	2.01x1.18x D	***	17.2%	50
findFirst	0.378ms±0.032	0.175ms±0.014	0.350ms	~1.00x	≈	28.0%	50
findFirst skip	0.328ms±0.107	0.147ms±0.0064	0.301ms	~1.00x	≈	15.2%	50
findUnique id	0.232ms±0.0097	0.102ms±0.0055	0.207ms	~1.00x	≈	18.6%	50
findUnique email	0.210ms±0.0072	0.090ms±0.0044	0.179ms	~1.00x	≈	17.1%	50
count	0.109ms±0.0033	0.063ms±0.0030	0.064ms	~1.00x	≈	16.2%	50
count where	0.469ms±0.015	0.247ms±0.016	0.287ms	~1.00x	≈	22.2%	50
aggregate count	0.215ms±0.0078	0.155ms±0.0042	—	~1.00x	≈	9.2%	50
aggregate sum/avg	0.305ms±0.014	0.261ms±0.0053	—	~1.00x	≈	7.1%	50
aggregate where	0.446ms±0.0100	0.239ms±0.0058	—	~1.00x	≈	8.7%	50
aggregate min/max	0.305ms±0.015	0.268ms±0.010	—	~1.00x	≈	13.2%	50
aggregate complete	0.381ms±0.0061	0.292ms±0.0072	—	~1.00x	≈	8.8%	50
groupBy	0.419ms±0.024	0.344ms±0.013	—	~1.00x	≈	12.8%	50
groupBy count	0.422ms±0.0100	0.358ms±0.0050	—	~1.00x	≈	4.8%	50
groupBy multi	0.544ms±0.013	0.442ms±0.052	—	~1.00x	≈	38.9%	50
groupBy having	0.505ms±0.011	0.375ms±0.0086	—	~1.00x	≈	8.2%	50
groupBy + where	0.550ms±0.011	0.294ms±0.0064	—	~1.00x	≈	7.8%	50
_count via include	0.679ms±0.013	0.511ms±0.013	—	~1.00x	≈	8.9%	50
_count via include + relations	1.55ms±0.037	0.666ms±0.017	—	~1.00x	≈	9.3%	50
groupBy aggregates	0.557ms±0.0097	0.465ms±0.0091	—	~1.00x	≈	6.9%	50
groupBy min/max	0.531ms±0.0080	0.441ms±0.0053	—	~1.00x	≈	4.2%	50
include list + nested to-one	1.46ms±0.029	0.337ms±0.032	—	4.32x	***	30.2%	50
include list + nullable to-one	2.59ms±0.081	1.65ms±0.056	—	~1.00x	≈	11.9%	50
include posts	4.25ms±0.216	2.35ms±0.120	5.77ms	1.81x2.45x D	***	18.9%	50
include profile	0.635ms±0.871	0.540ms±0.241	0.648ms	~1.00x	≈	104.7%	50
include 3 levels	4.48ms±0.148	4.03ms±0.147	4.58ms	~1.00x	≈	13.6%	50
include 4 levels	5.61ms±0.182	3.39ms±0.132	4.65ms	1.65x1.37x D	***	13.9%	50
include + where	4.04ms±0.176	2.88ms±0.399	5.51ms	~1.00x	≈	46.7%	50
include + select nested	2.52ms±0.139	1.96ms±0.185	4.42ms	~1.00x	≈	31.8%	50
findMany startsWith	0.270ms±0.028	0.140ms±0.014	0.314ms	~1.00x	≈	35.4%	50
findMany endsWith	0.563ms±0.015	0.216ms±0.0069	0.369ms	~1.00x	≈	11.1%	50
findMany NOT contains	0.627ms±0.022	0.250ms±0.104	0.447ms	~1.00x	≈	121.8%	50
findMany LIKE	0.245ms±0.0094	0.111ms±0.0069	0.250ms	~1.00x	≈	21.9%	50
findMany <	25.55ms±0.398	7.55ms±0.292	10.60ms	3.39x1.40x D	***	13.4%	50
findMany <=	26.43ms±0.371	7.78ms±0.220	10.97ms	3.40x1.41x D	***	10.2%	50
findMany >	15.55ms±0.599	5.21ms±0.356	6.78ms	2.99x1.30x D	***	24.2%	50
findMany NOT IN	0.644ms±0.013	0.282ms±0.011	0.487ms	~1.00x	≈	13.4%	50
findMany isNot null	0.642ms±0.014	0.336ms±0.017	0.362ms	~1.00x	≈	18.6%	50
orderBy multi-field	4.99ms±0.190	1.55ms±0.076	1.88ms	3.22x1.21x D	***	17.0%	50
orderBy relation to-one	4.10ms±0.135	3.08ms±0.090	—	1.33x	***	10.2%	50
orderBy relation + scalar	5.02ms±0.258	3.63ms±0.205	—	1.39x	***	20.0%	50
orderBy nullable relation	4.08ms±0.300	2.94ms±0.181	—	1.39x	***	21.1%	50
orderBy deep relation	5.43ms±0.186	4.04ms±0.174	—	1.34x	***	14.9%	50
orderBy deep relation + scalar	6.34ms±0.135	4.62ms±0.100	—	1.37x	***	7.8%	50
distinct status	8.84ms±0.376	1.56ms±0.181	—	5.66x	***	36.9%	50
distinct multi	12.04ms±0.171	2.50ms±0.073	—	4.81x	***	10.3%	50
cursor composite tuple	1.61ms±0.025	1.13ms±0.017	—	~1.00x	≈	5.3%	50
cursor composite desc	1.75ms±0.037	1.31ms±0.021	—	~1.00x	≈	5.8%	50
cursor prefix of orderBy	2.70ms±0.188	1.66ms±0.082	—	1.63x	***	18.1%	50
select + include	1.60ms±0.101	0.309ms±0.021	0.568ms	5.16x1.84x D	***	24.6%	50
_count relation	1.74ms±0.341	1.67ms±0.781	—	~1.00x	≈	123.8%	50
_count multi-relation	0.257ms±0.029	0.218ms±0.045	—	~1.00x	≈	62.4%	50
_count inside include	2.32ms±0.126	1.55ms±0.124	—	~1.00x	≈	32.0%	50
_count inside nested select	4.64ms±0.202	3.69ms±0.266	—	~1.00x	≈	24.3%	50
_count deep include	5.49ms±0.247	3.98ms±0.158	—	1.38x	***	14.1%	50
ILIKE special chars	0.425ms±0.033	0.193ms±0.022	—	~1.00x	≈	36.5%	50
LIKE case sensitive	0.263ms±0.010	0.110ms±0.0078	—	~1.00x	≈	24.0%	50
findMany Date range	0.424ms±0.012	0.190ms±0.012	0.321ms	~1.00x	≈	21.1%	50
count Date range	1.14ms±0.047	0.925ms±0.052	0.995ms	~1.00x	≈	19.8%	50
findMany Date gte	0.403ms±0.025	0.178ms±0.0058	0.303ms	~1.00x	≈	11.6%	50
depth-1 low-fan	0.566ms±0.021	0.447ms±0.102	—	~1.00x	≈	73.7%	50
depth-1 mid-fan	4.21ms±0.110	2.34ms±0.178	—	1.80x	***	26.3%	50
depth-1 high-fan	4.16ms±0.122	2.25ms±0.130	—	1.85x	***	20.4%	50
depth-1 wide	3.11ms±0.114	1.78ms±0.166	—	1.75x	***	31.3%	50
depth-1 unbound	39.65ms±3.78	9.43ms±0.884	—	4.21x	***	29.1%	50
depth-2	4.78ms±0.153	3.54ms±0.187	—	1.35x	***	18.6%	50
depth-2 paginated Project→tasks	3.16ms±0.149	2.68ms±0.161	—	~1.00x	≈	20.6%	50
depth-2 high-fan	3.84ms±0.185	2.86ms±0.229	—	~1.00x	≈	28.7%	50
depth-2 wide	4.90ms±0.176	3.08ms±0.176	—	1.59x	***	20.6%	50
depth-2 unbound	65.60ms±1.52	17.60ms±0.479	—	3.73x	***	4.4%	10
depth-3 unbound	15.32ms±0.281	8.38ms±0.354	—	1.83x	***	15.8%	50
depth-3 paginated	2.44ms±0.156	2.34ms±0.253	—	~1.00x	≈	32.7%	50
depth-4 unbound	9.96ms±0.268	6.14ms±0.266	—	1.62x	***	15.7%	50
depth-4 paginated	3.42ms±0.161	2.42ms±0.175	—	~1.00x	≈	23.6%	50
findFirst depth-2	2.91ms±0.114	2.30ms±0.173	—	~1.00x	≈	25.9%	50
findUnique depth-2 Project→tasks→comment	3.27ms±0.113	2.16ms±0.173	—	1.52x	***	27.5%	50
complex nested select	4.51ms±0.428	3.01ms±0.777	—	~1.00x	≈	65.7%	50
ultra deep query	15.94ms±0.546	5.83ms±0.361	—	2.73x	***	22.0%	50
transaction: (3 operations)	3.00ms±0.275	1.41ms±0.246	—	2.14x	***	53.2%	50

*** p < 0.001** p < 0.01* p < 0.05ns non significatif≈ dans le seuil de bruit de 1 ms± IC à 95 %CV% > 15% = forte variance

Mode runtime mesuré. Le mode prérendu évite entièrement la conversion requête-vers-SQL au runtime — attendez-vous à une latence plus faible que celle affichée ici, en particulier pour les requêtes complexes où le coût de conversion est proportionnellement plus élevé.

PostgreSQLPrisma v7 (7.10.0)

Moyenne 1.47x vs PrismaMoyenne 1.51x vs Drizzle18/95 gains significatifs77 dans le seuil de bruit

30 sept. 2026

Test	Prisma	prisma-sql	Drizzle	Accélération	Sig.	CV%	n
findMany basic	0.274ms±0.012	0.223ms±0.072	0.252ms	~1.00x	≈	97.3%	50
findMany where =	0.212ms±0.0047	0.158ms±0.0044	0.244ms	~1.00x	≈	9.6%	50
findMany where >=	7.36ms±0.258	4.63ms±0.213	6.57ms	1.59x1.42x D	***	16.5%	50
findMany where IN	0.372ms±0.027	0.231ms±0.015	0.410ms	~1.00x	≈	21.1%	50
findMany where null	0.111ms±0.084	0.091ms±0.0072	0.106ms	~1.00x	≈	26.6%	50
findMany ILIKE	0.120ms±0.0036	0.088ms±0.0025	0.154ms	~1.00x	≈	10.0%	50
findMany AND	0.968ms±0.013	0.540ms±0.093	0.705ms	~1.00x	≈	56.3%	50
findMany OR	7.35ms±0.343	3.95ms±0.218	5.27ms	1.86x1.33x D	***	19.1%	50
findMany NOT	0.361ms±0.022	0.231ms±0.121	0.411ms	~1.00x	≈	149.0%	50
findMany orderBy	2.04ms±0.073	0.581ms±0.022	0.706ms	3.50x1.22x D	***	13.5%	50
findMany pagination	0.156ms±0.0097	0.138ms±0.110	0.232ms	~1.00x	≈	201.6%	50
findMany select	0.113ms±0.0050	0.120ms±0.0053	0.101ms	~1.00x	≈	15.6%	50
findMany relation some	0.527ms±0.0044	0.404ms±0.0050	—	~1.00x	≈	4.4%	50
findMany relation every	0.515ms±0.0058	0.360ms±0.0069	—	~1.00x	≈	7.0%	50
findMany relation none	9.89ms±0.305	8.53ms±0.378	—	1.16x	***	16.7%	50
findMany nested relation	0.578ms±0.016	0.392ms±0.045	—	~1.00x	≈	38.6%	50
findMany complex	0.799ms±0.016	0.461ms±0.083	0.587ms	~1.00x	≈	57.8%	50
findFirst	0.132ms±0.0047	0.101ms±0.011	0.197ms	~1.00x	≈	35.7%	50
findFirst skip	0.135ms±0.048	0.105ms±0.025	0.189ms	~1.00x	≈	64.2%	50
findUnique id	0.107ms±0.024	0.070ms±0.015	0.130ms	~1.00x	≈	65.1%	50
findUnique email	0.106ms±0.0050	0.065ms±0.0097	0.128ms	~1.00x	≈	47.4%	50
count	0.079ms±0.0036	0.060ms±0.0028	0.059ms	~1.00x	≈	16.4%	50
count where	0.398ms±0.0086	0.239ms±0.013	0.272ms	~1.00x	≈	18.4%	50
aggregate count	0.174ms±0.0019	0.146ms±0.0022	—	~1.00x	≈	5.1%	50
aggregate sum/avg	0.265ms±0.0033	0.248ms±0.0033	—	~1.00x	≈	5.0%	50
aggregate where	0.369ms±0.0047	0.229ms±0.0030	—	~1.00x	≈	4.7%	50
aggregate min/max	0.256ms±0.0036	0.247ms±0.0030	—	~1.00x	≈	4.6%	50
aggregate complete	0.325ms±0.0036	0.284ms±0.0033	—	~1.00x	≈	4.3%	50
groupBy	0.360ms±0.022	0.349ms±0.0072	—	~1.00x	≈	7.4%	50
groupBy count	0.368ms±0.0072	0.359ms±0.012	—	~1.00x	≈	11.7%	50
groupBy multi	0.460ms±0.0089	0.453ms±0.016	—	~1.00x	≈	12.3%	50
groupBy having	0.432ms±0.0075	0.409ms±0.050	—	~1.00x	≈	41.0%	50
groupBy + where	0.425ms±0.0030	0.278ms±0.0039	—	~1.00x	≈	5.0%	50
_count via include	0.606ms±0.0055	0.533ms±0.012	—	~1.00x	≈	7.8%	50
_count via include + relations	1.16ms±0.011	0.635ms±0.0091	—	~1.00x	≈	5.1%	50
groupBy aggregates	0.479ms±0.0064	0.465ms±0.0044	—	~1.00x	≈	3.4%	50
groupBy min/max	0.462ms±0.051	0.452ms±0.0044	—	~1.00x	≈	3.6%	50
include list + nested to-one	0.941ms±0.015	0.324ms±0.013	—	~1.00x	≈	13.8%	50
include list + nullable to-one	1.29ms±0.196	1.53ms±0.027	—	~1.00x	≈	6.2%	50
include posts	1.36ms±0.143	1.29ms±0.111	2.55ms	~1.00x	≈	29.7%	50
include profile	0.316ms±0.027	0.248ms±0.029	0.462ms	~1.00x	≈	35.6%	50
include 3 levels	1.80ms±0.210	1.92ms±0.190	2.50ms	~1.00x	≈	32.2%	50
include 4 levels	5.99ms±0.553	4.24ms±0.269	5.54ms	1.41x1.31x D	***	22.9%	50
include + where	2.43ms±0.202	2.31ms±0.251	1.58ms	~1.00x	≈	35.6%	50
include + select nested	1.90ms±0.238	2.15ms±0.330	4.86ms	~1.00x	≈	52.6%	50
findMany startsWith	0.124ms±0.011	0.089ms±0.0075	0.183ms	~1.00x	≈	27.5%	50
findMany endsWith	0.235ms±0.011	0.165ms±0.0036	0.252ms	~1.00x	≈	8.0%	50
findMany NOT contains	0.218ms±0.0069	0.158ms±0.0047	0.234ms	~1.00x	≈	10.7%	50
findMany LIKE	0.081ms±0.0039	0.051ms±0.0022	0.103ms	~1.00x	≈	14.9%	50
findMany <	10.36ms±0.265	6.60ms±0.759	8.31ms	1.57x1.26x D	***	37.6%	50
findMany <=	11.00ms±0.608	6.71ms±0.552	8.80ms	1.64x1.31x D	***	28.2%	50
findMany >	7.08ms±0.345	4.40ms±0.411	6.08ms	1.61x1.38x D	***	30.2%	50
findMany NOT IN	0.381ms±0.064	0.241ms±0.042	0.437ms	~1.00x	≈	55.8%	50
findMany isNot null	0.212ms±0.011	0.168ms±0.011	0.197ms	~1.00x	≈	22.0%	50
orderBy multi-field	2.04ms±0.039	0.560ms±0.016	0.662ms	3.64x1.18x D	***	10.1%	50
orderBy relation to-one	1.87ms±0.049	1.39ms±0.052	—	~1.00x	≈	13.0%	50
orderBy relation + scalar	1.95ms±0.057	1.46ms±0.057	—	~1.00x	≈	13.4%	50
orderBy nullable relation	1.59ms±0.032	1.15ms±0.018	—	~1.00x	≈	5.8%	50
orderBy deep relation	2.09ms±0.121	1.61ms±0.072	—	~1.00x	≈	15.3%	50
orderBy deep relation + scalar	2.61ms±0.124	2.10ms±0.305	—	~1.00x	≈	45.9%	50
distinct status	7.73ms±0.274	1.28ms±0.051	—	6.03x	***	13.9%	50
distinct multi	11.00ms±0.363	2.54ms±0.220	—	4.33x	***	28.5%	50
cursor composite tuple	1.39ms±0.0067	1.09ms±0.0078	—	~1.00x	≈	2.5%	50
cursor composite desc	1.84ms±0.114	1.45ms±0.080	—	~1.00x	≈	18.9%	50
cursor prefix of orderBy	2.61ms±0.123	2.01ms±0.099	—	~1.00x	≈	17.7%	50
select + include	1.06ms±0.039	0.335ms±0.022	0.594ms	~1.00x	≈	22.8%	50
_count relation	1.66ms±0.123	1.80ms±0.107	—	~1.00x	≈	22.1%	50
_count multi-relation	0.737ms±0.041	0.715ms±0.041	—	~1.00x	≈	20.0%	50
_count inside include	4.12ms±0.256	2.85ms±0.151	—	1.45x	***	19.5%	50
_count inside nested select	1.54ms±0.078	1.45ms±0.091	—	~1.00x	≈	21.3%	50
_count deep include	2.19ms±0.135	1.76ms±0.083	—	~1.00x	≈	16.0%	50
ILIKE special chars	0.184ms±0.028	0.139ms±0.025	—	~1.00x	≈	52.5%	50
LIKE case sensitive	0.135ms±0.0061	0.099ms±0.0044	—	~1.00x	≈	15.2%	50
findMany Date range	0.150ms±0.0067	0.113ms±0.0055	0.205ms	~1.00x	≈	16.7%	50
count Date range	0.353ms±0.0050	0.316ms±0.0047	0.343ms	~1.00x	≈	5.4%	50
findMany Date gte	0.145ms±0.0078	0.105ms±0.0067	0.177ms	~1.00x	≈	21.7%	50
depth-1 low-fan	0.211ms±0.049	0.155ms±0.029	—	~1.00x	≈	55.6%	50
depth-1 mid-fan	1.03ms±0.123	0.959ms±0.142	—	~1.00x	≈	47.4%	50
depth-1 high-fan	0.840ms±0.107	0.791ms±0.011	—	~1.00x	≈	4.7%	50
depth-1 wide	0.789ms±0.120	0.826ms±0.037	—	~1.00x	≈	15.5%	50
depth-1 unbound	17.14ms±0.884	8.82ms±0.673	—	1.94x	***	25.0%	50
depth-2	3.76ms±0.234	3.72ms±0.175	—	~1.00x	≈	17.0%	50
depth-2 paginated Project→tasks	2.36ms±0.296	2.73ms±0.275	—	~1.00x	≈	40.8%	50
depth-2 high-fan	3.13ms±0.208	3.08ms±0.108	—	~1.00x	≈	12.4%	50
depth-2 wide	3.11ms±0.244	3.16ms±0.207	—	~1.00x	≈	22.5%	50
depth-2 unbound	30.14ms±1.02	17.11ms±0.944	—	1.76x	***	19.2%	50
depth-3 unbound	10.80ms±0.443	8.68ms±0.371	—	1.25x	***	15.1%	50
depth-3 paginated	1.19ms±0.112	1.10ms±0.105	—	~1.00x	≈	31.3%	50
depth-4 unbound	4.88ms±0.333	4.59ms±0.360	—	~1.00x	≈	28.9%	50
depth-4 paginated	1.31ms±0.047	0.976ms±0.068	—	~1.00x	≈	23.6%	50
findFirst depth-2	0.853ms±0.024	0.831ms±0.078	—	~1.00x	≈	31.1%	50
findUnique depth-2 Project→tasks→comment	0.846ms±0.093	0.727ms±0.021	—	~1.00x	≈	9.8%	50
complex nested select	2.88ms±0.093	1.82ms±0.035	—	1.58x	***	6.9%	50
ultra deep query	11.34ms±0.241	7.04ms±0.089	—	1.61x	***	4.5%	50
transaction: (3 operations)	3.29ms±0.313	1.56ms±0.311	—	2.12x	***	62.9%	50

*** p < 0.001** p < 0.01* p < 0.05ns non significatif≈ dans le seuil de bruit de 1 ms± IC à 95 %CV% > 15% = forte variance

PostgreSQLPrisma v8 (8.1.0-dev.1)

Moyenne 1.54x vs PrismaMoyenne 1.63x vs Drizzle17/95 gains significatifs78 dans le seuil de bruit

30 sept. 2026

Test	Prisma	prisma-sql	Drizzle	Accélération	Sig.	CV%	n
findMany basic	0.279ms±0.016	0.236ms±0.024	0.275ms	~1.00x	≈	32.6%	50
findMany where =	0.362ms±0.186	0.245ms±0.075	0.413ms	~1.00x	≈	89.0%	50
findMany where >=	8.32ms±0.363	4.81ms±0.542	6.99ms	1.73x1.45x D	***	37.4%	50
findMany where IN	0.383ms±0.014	0.254ms±0.011	0.420ms	~1.00x	≈	14.9%	50
findMany where null	0.166ms±0.013	0.137ms±0.084	0.150ms	~1.00x	≈	166.4%	50
findMany ILIKE	0.115ms±0.0053	0.083ms±0.0033	0.146ms	~1.00x	≈	14.0%	50
findMany AND	0.973ms±0.077	0.550ms±0.043	0.713ms	~1.00x	≈	26.8%	50
findMany OR	7.35ms±0.505	4.16ms±0.242	5.12ms	1.77x1.23x D	***	20.6%	50
findMany NOT	0.505ms±0.102	0.273ms±0.017	0.521ms	~1.00x	≈	21.2%	50
findMany orderBy	3.11ms±0.101	1.12ms±0.072	1.32ms	2.78x1.18x D	***	24.9%	50
findMany pagination	0.167ms±0.0100	0.135ms±0.013	0.246ms	~1.00x	≈	31.6%	50
findMany select	0.117ms±0.138	0.119ms±0.0083	0.101ms	~1.00x	≈	23.5%	50
findMany relation some	0.543ms±0.025	0.389ms±0.019	—	~1.00x	≈	16.4%	50
findMany relation every	0.551ms±0.0078	0.388ms±0.0069	—	~1.00x	≈	6.3%	50
findMany relation none	10.52ms±0.391	8.40ms±0.373	—	1.25x	***	16.8%	50
findMany nested relation	0.558ms±0.011	0.371ms±0.0069	—	~1.00x	≈	6.7%	50
findMany complex	0.769ms±0.020	0.451ms±0.0089	0.584ms	~1.00x	≈	7.1%	50
findFirst	0.135ms±0.0072	0.101ms±0.0039	0.195ms	~1.00x	≈	13.3%	50
findFirst skip	0.110ms±0.0072	0.077ms±0.0033	0.151ms	~1.00x	≈	15.7%	50
findUnique id	0.103ms±0.0028	0.065ms±0.0014	0.127ms	~1.00x	≈	8.2%	50
findUnique email	0.099ms±0.0025	0.066ms±0.0028	0.125ms	~1.00x	≈	14.9%	50
count	0.081ms±0.0039	0.062ms±0.0019	0.061ms	~1.00x	≈	11.1%	50
count where	0.381ms±0.0086	0.241ms±0.0036	0.273ms	~1.00x	≈	5.5%	50
aggregate count	0.178ms±0.0033	0.148ms±0.0025	—	~1.00x	≈	5.9%	50
aggregate sum/avg	0.268ms±0.0050	0.250ms±0.0033	—	~1.00x	≈	4.6%	50
aggregate where	0.369ms±0.0039	0.237ms±0.0033	—	~1.00x	≈	5.2%	50
aggregate min/max	0.263ms±0.0039	0.252ms±0.0036	—	~1.00x	≈	5.1%	50
aggregate complete	0.331ms±0.011	0.294ms±0.065	—	~1.00x	≈	70.0%	50
groupBy	0.346ms±0.0061	0.337ms±0.0047	—	~1.00x	≈	5.1%	50
groupBy count	0.367ms±0.0047	0.355ms±0.0047	—	~1.00x	≈	4.8%	50
groupBy multi	0.463ms±0.0091	0.442ms±0.010	—	~1.00x	≈	8.1%	50
groupBy having	0.407ms±0.017	0.379ms±0.013	—	~1.00x	≈	11.7%	50
groupBy + where	0.393ms±0.016	0.257ms±0.0064	—	~1.00x	≈	8.6%	50
_count via include	0.564ms±0.013	0.484ms±0.0097	—	~1.00x	≈	7.1%	50
_count via include + relations	1.19ms±0.089	0.657ms±0.016	—	~1.00x	≈	8.8%	50
groupBy aggregates	0.462ms±0.013	0.455ms±0.0075	—	~1.00x	≈	5.9%	50
groupBy min/max	0.454ms±0.0050	0.446ms±0.0058	—	~1.00x	≈	4.8%	50
include list + nested to-one	0.967ms±0.060	0.339ms±0.014	—	~1.00x	≈	14.2%	50
include list + nullable to-one	1.33ms±0.110	1.64ms±0.096	—	~1.00x	≈	20.4%	50
include posts	1.24ms±0.160	1.21ms±0.116	2.31ms	~1.00x	≈	30.5%	50
include profile	0.373ms±0.031	0.287ms±0.039	0.519ms	~1.00x	≈	38.7%	50
include 3 levels	2.78ms±0.435	2.80ms±0.203	3.36ms	~1.00x	≈	29.4%	50
include 4 levels	1.64ms±0.609	1.36ms±0.245	1.83ms	~1.00x	≈	47.0%	50
include + where	1.84ms±0.089	1.76ms±0.172	4.45ms	~1.00x	≈	34.6%	50
include + select nested	0.957ms±0.165	1.02ms±0.161	2.90ms	~1.00x	≈	43.0%	50
findMany startsWith	0.127ms±0.011	0.097ms±0.0061	0.194ms	~1.00x	≈	21.8%	50
findMany endsWith	0.260ms±0.0094	0.189ms±0.080	0.295ms	~1.00x	≈	119.6%	50
findMany NOT contains	0.225ms±0.0058	0.165ms±0.0030	0.242ms	~1.00x	≈	6.3%	50
findMany LIKE	0.090ms±0.0061	0.061ms±0.0042	0.121ms	~1.00x	≈	24.6%	50
findMany <	11.95ms±1.04	6.55ms±0.246	8.71ms	1.82x1.33x D	***	13.2%	50
findMany <=	12.08ms±1.58	6.74ms±0.432	8.73ms	1.79x1.30x D	***	21.8%	50
findMany >	7.81ms±0.481	4.60ms±0.239	5.86ms	1.70x1.27x D	***	18.7%	50
findMany NOT IN	0.358ms±0.077	0.226ms±0.013	0.391ms	~1.00x	≈	19.2%	50
findMany isNot null	0.283ms±0.012	0.229ms±0.0094	0.253ms	~1.00x	≈	15.5%	50
orderBy multi-field	1.88ms±0.042	0.522ms±0.071	0.590ms	3.60x1.13x D	***	46.1%	50
orderBy relation to-one	1.69ms±0.021	1.29ms±0.031	—	~1.00x	≈	8.5%	50
orderBy relation + scalar	2.69ms±0.218	2.05ms±0.176	—	~1.00x	≈	30.7%	50
orderBy nullable relation	1.59ms±0.198	1.15ms±0.027	—	~1.00x	≈	8.3%	50
orderBy deep relation	1.91ms±0.018	1.50ms±0.013	—	~1.00x	≈	3.1%	50
orderBy deep relation + scalar	2.33ms±0.124	1.90ms±0.085	—	~1.00x	≈	14.8%	50
distinct status	7.76ms±0.096	1.30ms±0.091	—	5.98x	***	24.1%	50
distinct multi	11.01ms±0.071	2.47ms±0.035	—	4.45x	***	5.1%	50
cursor composite tuple	1.45ms±0.016	1.13ms±0.018	—	~1.00x	≈	5.7%	50
cursor composite desc	1.59ms±0.0100	1.27ms±0.0100	—	~1.00x	≈	2.8%	50
cursor prefix of orderBy	1.53ms±0.251	1.17ms±0.167	—	~1.00x	≈	40.3%	50
select + include	0.619ms±0.015	0.206ms±0.013	0.370ms	~1.00x	≈	21.4%	50
_count relation	0.581ms±0.0050	0.596ms±0.0055	—	~1.00x	≈	3.4%	50
_count multi-relation	0.193ms±0.0069	0.183ms±0.0044	—	~1.00x	≈	8.4%	50
_count inside include	0.910ms±0.020	0.633ms±0.013	—	~1.00x	≈	7.3%	50
_count inside nested select	1.37ms±0.020	1.18ms±0.017	—	~1.00x	≈	5.1%	50
_count deep include	1.52ms±0.015	1.20ms±0.020	—	~1.00x	≈	5.9%	50
ILIKE special chars	0.148ms±0.0053	0.120ms±0.0042	—	~1.00x	≈	11.8%	50
LIKE case sensitive	0.117ms±0.0028	0.087ms±0.0019	—	~1.00x	≈	7.4%	50
findMany Date range	1.28ms±0.012	0.139ms±0.032	0.549ms	9.27x3.96x D	***	62.7%	50
count Date range	0.389ms±0.0064	0.349ms±0.0067	0.409ms	~1.00x	≈	6.9%	50
findMany Date gte	0.169ms±0.0039	0.130ms±0.0028	0.227ms	~1.00x	≈	7.8%	50
depth-1 low-fan	0.199ms±0.0050	0.133ms±0.0036	—	~1.00x	≈	9.8%	50
depth-1 mid-fan	0.997ms±0.103	0.915ms±0.073	—	~1.00x	≈	27.5%	50
depth-1 high-fan	0.904ms±0.102	0.890ms±0.109	—	~1.00x	≈	41.3%	50
depth-1 wide	0.857ms±0.091	0.925ms±0.019	—	~1.00x	≈	7.4%	50
depth-1 unbound	17.36ms±0.533	9.64ms±0.963	—	1.80x	***	31.6%	50
depth-2	2.64ms±0.122	2.78ms±0.226	—	~1.00x	≈	28.5%	50
depth-2 paginated Project→tasks	0.991ms±0.075	1.17ms±0.112	—	~1.00x	≈	31.1%	50
depth-2 high-fan	1.31ms±0.145	1.32ms±0.096	—	~1.00x	≈	22.5%	50
depth-2 wide	2.47ms±0.216	2.45ms±0.193	—	~1.00x	≈	25.7%	50
depth-2 unbound	28.05ms±0.484	15.71ms±0.461	—	1.79x	***	10.5%	50
depth-3 unbound	8.51ms±0.281	7.07ms±0.491	—	1.20x	***	24.1%	50
depth-3 paginated	1.68ms±0.183	1.64ms±0.160	—	~1.00x	≈	31.7%	50
depth-4 unbound	6.55ms±0.301	6.09ms±0.342	—	~1.00x	≈	19.7%	50
depth-4 paginated	1.43ms±0.162	1.18ms±0.192	—	~1.00x	≈	47.1%	50
findFirst depth-2	0.987ms±0.094	0.971ms±0.019	—	~1.00x	≈	7.1%	50
findUnique depth-2 Project→tasks→comment	1.53ms±0.135	1.39ms±0.062	—	~1.00x	≈	15.8%	50
complex nested select	3.37ms±0.296	2.05ms±0.185	—	1.64x	***	27.8%	50
ultra deep query	12.44ms±0.689	7.71ms±0.293	—	1.61x	***	13.2%	50
transaction: (3 operations)	10.90ms±0.134	9.07ms±0.081	—	1.20x	***	3.2%	50

*** p < 0.001** p < 0.01* p < 0.05ns non significatif≈ dans le seuil de bruit de 1 ms± IC à 95 %CV% > 15% = forte variance

SQLitePrisma v6 (6.19.3)

Moyenne 4.80x vs PrismaMoyenne 1.79x vs Drizzle22/84 gains significatifs62 dans le seuil de bruit

30 sept. 2026

Test	Prisma	prisma-sql	Drizzle	Accélération	Sig.	CV%	n
findMany basic	0.449ms±0.019	0.070ms±0.0083	0.116ms	~1.00x	≈	37.1%	50
findMany where =	0.380ms±0.0075	0.055ms±0.0025	0.093ms	~1.00x	≈	15.4%	50
findMany where >=	13.30ms±0.272	1.33ms±0.039	2.14ms	10.03x1.61x D	***	10.3%	50
findMany where IN	0.432ms±0.012	0.063ms±0.0033	0.114ms	~1.00x	≈	18.2%	50
findMany where null	0.167ms±0.0047	0.025ms±0.0030	0.057ms	~1.00x	≈	37.9%	50
findMany AND	1.55ms±0.141	0.302ms±0.041	0.424ms	5.12x1.40x D	***	42.4%	50
findMany OR	10.21ms±0.128	1.12ms±0.023	1.80ms	9.12x1.61x D	***	7.5%	50
findMany NOT	0.436ms±0.017	0.055ms±0.0033	0.103ms	~1.00x	≈	20.5%	50
findMany orderBy	2.37ms±0.033	1.83ms±0.021	1.88ms	~1.00x	≈	4.1%	50
findMany pagination	0.147ms±0.012	0.037ms±0.0028	0.066ms	~1.00x	≈	24.7%	50
findMany select	0.173ms±0.0044	0.047ms±0.0019	0.041ms	~1.00x	≈	15.2%	50
findMany relation some	4.56ms±0.020	0.446ms±0.0094	—	10.21x	***	7.5%	50
findMany relation every	9.74ms±0.108	6.35ms±0.059	—	1.53x	***	3.3%	50
findMany relation none	169.69ms±3.84	2.81ms±0.108	—	60.47x	***	6.0%	10
findMany nested relation	1.04ms±0.018	0.316ms±0.022	—	~1.00x	≈	23.5%	50
findMany complex	0.814ms±0.084	0.405ms±0.0086	0.454ms	~1.00x	≈	7.4%	50
findFirst	0.163ms±0.021	0.035ms±0.0072	0.074ms	~1.00x	≈	59.4%	50
findFirst skip	0.184ms±0.126	0.036ms±0.0083	0.081ms	~1.00x	≈	66.4%	50
findUnique id	0.134ms±0.0033	0.032ms±0.0017	0.059ms	~1.00x	≈	17.1%	50
findUnique email	0.123ms±0.0017	0.029ms±0.0008	0.056ms	~1.00x	≈	10.5%	50
count	0.068ms±0.0019	0.016ms±0.0008	0.019ms	~1.00x	≈	18.3%	50
count where	0.268ms±0.0025	0.164ms±0.0019	0.169ms	~1.00x	≈	4.2%	50
_count via include	0.537ms±0.0067	0.232ms±0.0061	—	~1.00x	≈	9.4%	50
_count via include + relations	1.06ms±0.0055	0.276ms±0.0055	—	~1.00x	≈	7.2%	50
aggregate count	0.144ms±0.0044	0.027ms±0.0017	—	~1.00x	≈	20.4%	50
aggregate sum/avg	0.274ms±0.0022	0.168ms±0.0019	—	~1.00x	≈	4.1%	50
aggregate where	0.262ms±0.0025	0.166ms±0.0030	—	~1.00x	≈	6.5%	50
aggregate min/max	0.306ms±0.0022	0.175ms±0.0025	—	~1.00x	≈	5.1%	50
aggregate complete	0.390ms±0.0025	0.234ms±0.0028	—	~1.00x	≈	4.4%	50
groupBy	0.572ms±0.0089	0.454ms±0.0061	—	~1.00x	≈	4.8%	50
groupBy count	0.567ms±0.0061	0.453ms±0.0047	—	~1.00x	≈	3.8%	50
groupBy multi	1.17ms±0.0072	0.971ms±0.0075	—	~1.00x	≈	2.8%	50
groupBy having	0.635ms±0.0091	0.485ms±0.0047	—	~1.00x	≈	3.5%	50
groupBy + where	0.325ms±0.065	0.204ms±0.0036	—	~1.00x	≈	6.2%	50
groupBy aggregates	0.703ms±0.0078	0.578ms±0.0044	—	~1.00x	≈	2.8%	50
groupBy min/max	0.718ms±0.0055	0.583ms±0.0036	—	~1.00x	≈	2.2%	50
include posts	2.00ms±0.041	0.421ms±0.021	1.34ms	4.75x3.18x D	***	16.9%	50
include profile	0.333ms±0.0097	0.066ms±0.0022	0.191ms	~1.00x	≈	11.9%	50
include 3 levels	1.11ms±0.032	0.642ms±0.0064	0.817ms	~1.00x	≈	3.6%	50
include 4 levels	1.14ms±0.0075	0.423ms±0.0050	0.634ms	~1.00x	≈	4.1%	50
include + where	0.777ms±0.021	0.289ms±0.0058	0.271ms	~1.00x	≈	7.1%	50
include + select nested	0.778ms±0.026	0.317ms±0.0067	0.953ms	~1.00x	≈	7.5%	50
findMany startsWith	0.157ms±0.0064	0.035ms±0.0014	0.059ms	~1.00x	≈	14.2%	50
findMany endsWith	0.459ms±0.0064	0.067ms±0.0022	0.106ms	~1.00x	≈	11.1%	50
findMany NOT contains	0.455ms±0.058	0.054ms±0.0019	0.095ms	~1.00x	≈	11.6%	50
findMany LIKE	0.156ms±0.0022	0.034ms±0.0017	0.057ms	~1.00x	≈	17.2%	50
findMany <	21.45ms±0.104	2.21ms±0.316	3.56ms	9.69x1.61x D	***	41.4%	50
findMany <=	22.25ms±0.096	2.23ms±0.235	3.69ms	9.96x1.65x D	***	33.3%	50
findMany >	11.74ms±0.116	1.15ms±0.161	1.92ms	10.21x1.67x D	***	45.5%	50
findMany NOT IN	0.444ms±0.014	0.058ms±0.011	0.115ms	~1.00x	≈	56.6%	50
findMany isNot null	0.426ms±0.0055	0.051ms±0.0017	0.093ms	~1.00x	≈	11.6%	50
orderBy multi-field	0.671ms±0.069	0.350ms±0.0064	0.402ms	~1.00x	≈	6.5%	50
orderBy relation to-one	0.641ms±0.0055	0.319ms±0.0086	—	~1.00x	≈	9.4%	50
orderBy relation + scalar	0.714ms±0.0055	0.391ms±0.0039	—	~1.00x	≈	3.7%	50
orderBy nullable relation	0.608ms±0.0069	0.321ms±0.0025	—	~1.00x	≈	2.7%	50
orderBy deep relation	0.710ms±0.0086	0.380ms±0.0044	—	~1.00x	≈	4.3%	50
orderBy deep relation + scalar	1.10ms±0.010	0.694ms±0.0078	—	~1.00x	≈	4.0%	50
distinct status	10.99ms±0.072	4.09ms±0.035	—	2.68x	***	3.0%	50
distinct multi	12.12ms±0.092	4.96ms±0.013	—	2.44x	***	1.0%	50
select + include	0.537ms±0.0061	0.066ms±0.0028	0.133ms	~1.00x	≈	14.1%	50
_count relation	0.611ms±0.0061	0.353ms±0.0039	—	~1.00x	≈	3.9%	50
_count multi-relation	0.132ms±0.0061	0.045ms±0.0036	—	~1.00x	≈	25.1%	50
_count inside include	0.861ms±0.0078	0.341ms±0.0058	—	~1.00x	≈	6.1%	50
_count inside nested select	1.54ms±0.010	0.587ms±0.0072	—	~1.00x	≈	4.5%	50
_count deep include	1.33ms±0.0083	0.730ms±0.0089	—	~1.00x	≈	4.3%	50
findMany Date range	0.259ms±0.0042	0.051ms±0.0014	0.230ms	~1.00x	≈	9.3%	50
count Date range	0.303ms±0.0050	0.180ms±0.0025	0.182ms	~1.00x	≈	5.1%	50
findMany Date gte	0.242ms±0.0033	0.049ms±0.0019	0.102ms	~1.00x	≈	13.1%	50
depth-1 low-fan Project→labels	0.257ms±0.0067	0.069ms±0.0042	—	~1.00x	≈	19.7%	50
depth-1 mid-fan Project→tasks	1.91ms±0.022	0.367ms±0.0083	—	5.21x	***	8.0%	50
depth-1 high-fan User→assignedTasks	1.65ms±0.062	0.332ms±0.0086	—	4.96x	***	9.2%	50
depth-1 wide	1.43ms±0.053	0.337ms±0.0061	—	4.25x	***	6.6%	50
depth-1 no-limit Project→tasks	33.39ms±0.407	3.56ms±0.378	—	9.39x	***	34.4%	50
depth-2	1.77ms±0.045	0.471ms±0.012	—	3.76x	***	9.4%	50
depth-2 paginated	0.896ms±0.0086	0.663ms±0.0067	—	~1.00x	≈	3.6%	50
depth-2 high-fan	1.56ms±0.034	0.416ms±0.012	—	3.76x	***	9.8%	50
depth-2 wide+attach+activity	1.86ms±0.031	0.532ms±0.013	—	3.49x	***	8.4%	50
depth-2 no-limit	49.34ms±0.687	6.75ms±0.300	—	7.31x	***	7.2%	10
depth-3	9.70ms±0.121	1.55ms±0.032	—	6.25x	***	7.3%	50
depth-3 paginated	1.07ms±0.0094	0.604ms±0.0067	—	~1.00x	≈	4.0%	50
depth-4	5.66ms±0.217	1.04ms±0.038	—	5.44x	***	12.8%	50
depth-4 paginated	1.12ms±0.079	0.418ms±0.0067	—	~1.00x	≈	5.6%	50
findFirst depth-2	0.906ms±0.0080	0.285ms±0.0083	—	~1.00x	≈	10.2%	50
findUnique depth-2	0.927ms±0.051	0.290ms±0.0083	—	~1.00x	≈	9.9%	50

*** p < 0.001** p < 0.01* p < 0.05ns non significatif≈ dans le seuil de bruit de 1 ms± IC à 95 %CV% > 15% = forte variance

SQLitePrisma v7 (7.10.0)

Moyenne 2.29x vs PrismaMoyenne 1.84x vs Drizzle13/84 gains significatifs71 dans le seuil de bruit

30 sept. 2026

Test	Prisma	prisma-sql	Drizzle	Accélération	Sig.	CV%	n
findMany basic	0.147ms±0.0033	0.056ms±0.0030	0.105ms	~1.00x	≈	17.1%	50
findMany where =	0.123ms±0.0025	0.051ms±0.0011	0.090ms	~1.00x	≈	6.8%	50
findMany where >=	3.70ms±0.269	1.21ms±0.017	2.15ms	3.05x1.77x D	***	5.0%	50
findMany where IN	0.140ms±0.251	0.057ms±0.0028	0.101ms	~1.00x	≈	17.1%	50
findMany where null	0.061ms±0.0019	0.024ms±0.0008	0.050ms	~1.00x	≈	12.3%	50
findMany AND	0.566ms±0.169	0.297ms±0.0055	0.410ms	~1.00x	≈	6.8%	50
findMany OR	3.08ms±0.218	1.09ms±0.186	1.86ms	2.82x1.70x D	***	53.4%	50
findMany NOT	0.147ms±0.239	0.058ms±0.0036	0.123ms	~1.00x	≈	21.1%	50
findMany orderBy	1.72ms±0.011	1.67ms±0.0097	1.71ms	~1.00x	≈	2.1%	50
findMany pagination	0.065ms±0.0025	0.037ms±0.012	0.060ms	~1.00x	≈	93.4%	50
findMany select	0.059ms±0.0011	0.046ms±0.0014	0.039ms	~1.00x	≈	10.4%	50
findMany relation some	0.383ms±0.012	0.430ms±0.100	—	~1.00x	≈	74.8%	50
findMany relation every	9.48ms±0.212	6.42ms±0.085	—	1.48x	***	4.7%	50
findMany relation none	126.50ms±8.87	3.10ms±0.084	—	40.78x	***	4.3%	10
findMany nested relation	0.369ms±0.012	0.304ms±0.0064	—	~1.00x	≈	7.3%	50
findMany complex	0.549ms±0.156	0.509ms±0.103	0.530ms	~1.00x	≈	55.5%	50
findFirst	0.065ms±0.0069	0.027ms±0.0014	0.060ms	~1.00x	≈	18.7%	50
findFirst skip	0.075ms±0.0080	0.029ms±0.0042	0.076ms	~1.00x	≈	43.6%	50
findUnique id	0.063ms±0.0025	0.023ms±0.0006	0.051ms	~1.00x	≈	10.0%	50
findUnique email	0.062ms±0.0030	0.024ms±0.0008	0.052ms	~1.00x	≈	13.8%	50
count	0.033ms±0.0014	0.014ms±0.0003	0.014ms	~1.00x	≈	10.2%	50
count where	0.201ms±0.0058	0.166ms±0.0025	0.168ms	~1.00x	≈	5.1%	50
_count via include	0.416ms±0.0089	0.224ms±0.0086	—	~1.00x	≈	13.5%	50
_count via include + relations	0.759ms±0.016	0.269ms±0.011	—	~1.00x	≈	14.1%	50
aggregate count	0.074ms±0.146	0.024ms±0.0022	—	~1.00x	≈	28.5%	50
aggregate sum/avg	0.259ms±0.142	0.195ms±0.134	—	~1.00x	≈	120.6%	50
aggregate where	0.201ms±0.073	0.174ms±0.057	—	~1.00x	≈	86.9%	50
aggregate min/max	0.206ms±0.0039	0.172ms±0.0030	—	~1.00x	≈	6.3%	50
aggregate complete	0.274ms±0.0097	0.238ms±0.0033	—	~1.00x	≈	5.1%	50
groupBy	0.475ms±0.0058	0.447ms±0.0069	—	~1.00x	≈	5.5%	50
groupBy count	0.494ms±0.016	0.467ms±0.0097	—	~1.00x	≈	7.3%	50
groupBy multi	0.987ms±0.020	0.973ms±0.019	—	~1.00x	≈	6.9%	50
groupBy having	0.503ms±0.0047	0.478ms±0.0044	—	~1.00x	≈	3.3%	50
groupBy + where	0.219ms±0.0014	0.198ms±0.0011	—	~1.00x	≈	2.2%	50
groupBy aggregates	0.577ms±0.0055	0.552ms±0.0033	—	~1.00x	≈	2.2%	50
groupBy min/max	0.584ms±0.0067	0.561ms±0.0083	—	~1.00x	≈	5.3%	50
include posts	0.834ms±0.109	0.435ms±0.029	1.35ms	~1.00x	≈	22.4%	50
include profile	0.138ms±0.128	0.065ms±0.0044	0.194ms	~1.00x	≈	22.1%	50
include 3 levels	0.609ms±0.148	0.566ms±0.014	0.762ms	~1.00x	≈	8.7%	50
include 4 levels	0.682ms±0.104	0.424ms±0.027	0.641ms	~1.00x	≈	21.2%	50
include + where	0.399ms±0.0053	0.271ms±0.0078	0.264ms	~1.00x	≈	9.9%	50
include + select nested	0.344ms±0.0072	0.302ms±0.085	0.971ms	~1.00x	≈	87.0%	50
findMany startsWith	0.056ms±0.0011	0.033ms±0.0003	0.055ms	~1.00x	≈	3.9%	50
findMany endsWith	0.143ms±0.0036	0.069ms±0.0047	0.118ms	~1.00x	≈	23.5%	50
findMany NOT contains	0.142ms±0.0014	0.057ms±0.0008	0.099ms	~1.00x	≈	4.8%	50
findMany LIKE	0.055ms±0.0014	0.032ms±0.0003	0.052ms	~1.00x	≈	4.4%	50
findMany <	6.81ms±4.28	2.47ms±0.428	3.96ms	2.75x1.60x D	**	52.3%	50
findMany <=	6.86ms±0.959	2.48ms±0.433	4.11ms	2.76x1.66x D	***	48.9%	50
findMany >	3.85ms±0.589	1.35ms±0.229	2.19ms	2.85x1.62x D	***	50.0%	50
findMany NOT IN	0.142ms±0.0036	0.056ms±0.0061	0.103ms	~1.00x	≈	35.5%	50
findMany isNot null	0.135ms±0.0028	0.054ms±0.0030	0.096ms	~1.00x	≈	20.0%	50
orderBy multi-field	0.437ms±0.0075	0.366ms±0.0067	0.421ms	~1.00x	≈	6.5%	50
orderBy relation to-one	0.392ms±0.0050	0.327ms±0.0086	—	~1.00x	≈	9.3%	50
orderBy relation + scalar	0.460ms±0.0028	0.398ms±0.0033	—	~1.00x	≈	2.9%	50
orderBy nullable relation	0.394ms±0.015	0.335ms±0.016	—	~1.00x	≈	16.3%	50
orderBy deep relation	2.14ms±1.01	1.59ms±1.77	—	~1.00x	≈	178.6%	50
orderBy deep relation + scalar	0.809ms±0.030	0.721ms±0.054	—	~1.00x	≈	25.0%	50
distinct status	6.38ms±2.53	4.55ms±0.932	—	1.40x	**	58.1%	50
distinct multi	7.42ms±0.707	5.78ms±0.551	—	1.28x	***	30.9%	50
select + include	0.300ms±0.0094	0.063ms±0.0083	0.132ms	~1.00x	≈	41.9%	50
_count relation	0.445ms±0.059	0.396ms±0.053	—	~1.00x	≈	41.8%	50
_count multi-relation	0.091ms±0.0064	0.045ms±0.0006	—	~1.00x	≈	5.3%	50
_count inside include	0.747ms±0.045	0.381ms±0.040	—	~1.00x	≈	32.5%	50
_count inside nested select	1.43ms±0.058	0.694ms±0.068	—	~1.00x	≈	31.4%	50
_count deep include	1.12ms±0.046	0.841ms±0.122	—	~1.00x	≈	47.5%	50
findMany Date range	0.102ms±0.0055	0.054ms±0.0047	0.311ms	~1.00x	≈	29.2%	50
count Date range	0.445ms±0.066	0.371ms±0.050	0.286ms	~1.00x	≈	42.0%	50
findMany Date gte	0.099ms±0.012	0.052ms±0.0072	0.089ms	~1.00x	≈	43.8%	50
depth-1 low-fan Project→labels	0.120ms±0.014	0.067ms±0.0044	—	~1.00x	≈	22.6%	50
depth-1 mid-fan Project→tasks	0.875ms±0.184	0.449ms±0.457	—	~1.00x	≈	221.0%	50
depth-1 high-fan User→assignedTasks	0.785ms±0.188	0.424ms±0.041	—	~1.00x	≈	31.4%	50
depth-1 wide	0.676ms±0.210	0.380ms±0.051	—	~1.00x	≈	41.2%	50
depth-1 no-limit Project→tasks	13.27ms±1.11	4.11ms±0.355	—	3.23x	***	27.1%	50
depth-2	0.808ms±0.422	0.468ms±0.212	—	~1.00x	≈	124.7%	50
depth-2 paginated	0.552ms±0.038	0.653ms±0.020	—	~1.00x	≈	10.6%	50
depth-2 high-fan	0.724ms±0.032	0.426ms±0.128	—	~1.00x	≈	88.3%	50
depth-2 wide+attach+activity	1.01ms±0.147	0.544ms±0.131	—	~1.00x	≈	73.6%	50
depth-2 no-limit	18.70ms±0.737	7.54ms±0.729	—	2.48x	***	29.4%	50
depth-3	3.63ms±0.429	1.54ms±0.348	—	2.36x	***	66.1%	50
depth-3 paginated	1.27ms±0.412	0.943ms±0.222	—	~1.00x	≈	63.7%	50
depth-4	2.67ms±0.426	1.23ms±0.214	—	2.16x	***	53.9%	50
depth-4 paginated	0.669ms±0.135	0.420ms±0.027	—	~1.00x	≈	20.9%	50
findFirst depth-2	0.508ms±0.149	0.296ms±0.019	—	~1.00x	≈	20.4%	50
findUnique depth-2	0.496ms±0.096	0.287ms±0.015	—	~1.00x	≈	17.4%	50

*** p < 0.001** p < 0.01* p < 0.05ns non significatif≈ dans le seuil de bruit de 1 ms± IC à 95 %CV% > 15% = forte variance

SQLitePrisma v8 (8.1.0-dev.1)

Moyenne 2.10x vs PrismaMoyenne 1.63x vs Drizzle14/84 gains significatifs70 dans le seuil de bruit

30 sept. 2026

Test	Prisma	prisma-sql	Drizzle	Accélération	Sig.	CV%	n
findMany basic	0.450ms±0.927	0.151ms±0.048	0.268ms	~1.00x	≈	72.4%	50
findMany where =	0.244ms±0.070	0.114ms±0.040	0.170ms	~1.00x	≈	80.5%	50
findMany where >=	7.43ms±1.10	3.18ms±1.15	4.17ms	2.34x1.31x D	***	98.5%	50
findMany where IN	0.284ms±0.065	0.117ms±0.041	0.169ms	~1.00x	≈	85.0%	50
findMany where null	0.138ms±0.035	0.052ms±0.023	0.082ms	~1.00x	≈	90.5%	50
findMany AND	1.61ms±0.206	0.836ms±0.120	0.976ms	~1.00x	≈	45.8%	50
findMany OR	5.29ms±0.590	2.24ms±0.382	3.25ms	2.36x1.45x D	***	55.5%	50
findMany NOT	0.197ms±0.040	0.081ms±0.026	0.126ms	~1.00x	≈	76.2%	50
findMany orderBy	4.11ms±0.759	3.79ms±0.449	3.61ms	~1.00x	≈	40.2%	50
findMany pagination	0.539ms±0.297	0.394ms±0.171	0.369ms	~1.00x	≈	103.6%	50
findMany select	0.252ms±0.121	0.223ms±0.086	0.126ms	~1.00x	≈	93.6%	50
findMany relation some	1.97ms±0.401	1.29ms±0.348	—	~1.00x	≈	71.5%	50
findMany relation every	15.08ms±4.43	10.50ms±1.19	—	1.44x	**	36.4%	50
findMany relation none	178.32ms±7.96	6.56ms±2.80	—	27.18x	***	45.7%	5
findMany nested relation	0.507ms±0.094	0.399ms±0.042	—	~1.00x	≈	34.8%	50
findMany complex	1.01ms±0.138	0.871ms±0.117	0.859ms	~1.00x	≈	43.3%	50
findFirst	0.080ms±0.033	0.034ms±0.030	0.070ms	~1.00x	≈	147.4%	50
findFirst skip	0.086ms±0.069	0.035ms±0.037	0.082ms	~1.00x	≈	154.8%	50
findUnique id	0.081ms±0.039	0.027ms±0.017	0.055ms	~1.00x	≈	115.3%	50
findUnique email	0.075ms±0.039	0.027ms±0.031	0.054ms	~1.00x	≈	202.7%	50
count	0.037ms±0.0072	0.016ms±0.0064	0.015ms	~1.00x	≈	90.1%	50
count where	0.427ms±0.070	0.278ms±0.052	0.253ms	~1.00x	≈	52.2%	50
_count via include	0.745ms±0.105	0.382ms±0.091	—	~1.00x	≈	58.8%	50
_count via include + relations	1.53ms±0.288	0.691ms±0.291	—	~1.00x	≈	105.5%	50
aggregate count	0.076ms±0.014	0.026ms±0.011	—	~1.00x	≈	112.6%	50
aggregate sum/avg	0.246ms±0.052	0.189ms±0.037	—	~1.00x	≈	55.2%	50
aggregate where	0.255ms±0.061	0.214ms±0.040	—	~1.00x	≈	52.2%	50
aggregate min/max	0.680ms±0.165	0.393ms±0.106	—	~1.00x	≈	69.7%	50
aggregate complete	0.568ms±0.292	0.391ms±0.095	—	~1.00x	≈	62.3%	50
groupBy	0.934ms±0.104	0.859ms±0.136	—	~1.00x	≈	50.0%	50
groupBy count	0.874ms±0.100	0.794ms±0.102	—	~1.00x	≈	41.1%	50
groupBy multi	1.74ms±0.119	1.53ms±0.141	—	~1.00x	≈	31.2%	50
groupBy having	0.843ms±0.131	0.747ms±0.098	—	~1.00x	≈	42.5%	50
groupBy + where	0.450ms±0.086	0.337ms±0.097	—	~1.00x	≈	70.0%	50
groupBy aggregates	1.09ms±0.124	0.917ms±0.116	—	~1.00x	≈	40.4%	50
groupBy min/max	1.18ms±0.096	0.890ms±0.095	—	~1.00x	≈	34.6%	50
include posts	1.45ms±0.231	0.892ms±0.190	2.55ms	~1.00x	≈	58.1%	50
include profile	0.147ms±0.028	0.071ms±0.017	0.202ms	~1.00x	≈	65.0%	50
include 3 levels	0.920ms±0.250	0.778ms±0.081	0.915ms	~1.00x	≈	33.8%	50
include 4 levels	0.799ms±0.085	0.465ms±0.049	0.670ms	~1.00x	≈	32.9%	50
include + where	0.810ms±0.401	0.571ms±0.173	0.508ms	~1.00x	≈	73.1%	50
include + select nested	0.645ms±0.153	0.591ms±0.074	1.20ms	~1.00x	≈	40.9%	50
findMany startsWith	0.071ms±0.016	0.041ms±0.0069	0.066ms	~1.00x	≈	52.4%	50
findMany endsWith	0.252ms±0.096	0.132ms±0.134	0.184ms	~1.00x	≈	184.3%	50
findMany NOT contains	0.296ms±0.112	0.102ms±0.085	0.192ms	~1.00x	≈	145.2%	50
findMany LIKE	0.113ms±0.055	0.063ms±0.042	0.099ms	~1.00x	≈	106.0%	50
findMany <	7.95ms±0.626	2.95ms±0.193	5.36ms	2.70x1.82x D	***	21.8%	50
findMany <=	9.47ms±0.948	3.46ms±0.432	5.03ms	2.73x1.45x D	***	39.8%	50
findMany >	5.61ms±0.633	1.98ms±0.501	2.93ms	2.83x1.48x D	***	73.5%	50
findMany NOT IN	0.231ms±0.235	0.086ms±0.026	0.132ms	~1.00x	≈	70.0%	50
findMany isNot null	0.183ms±0.062	0.079ms±0.035	0.115ms	~1.00x	≈	89.4%	50
orderBy multi-field	0.811ms±0.280	0.678ms±0.114	0.790ms	~1.00x	≈	48.5%	50
orderBy relation to-one	0.628ms±0.173	0.517ms±0.128	—	~1.00x	≈	63.8%	50
orderBy relation + scalar	0.550ms±0.063	0.443ms±0.027	—	~1.00x	≈	20.6%	50
orderBy nullable relation	0.455ms±0.088	0.385ms±0.060	—	~1.00x	≈	46.8%	50
orderBy deep relation	0.500ms±0.083	0.434ms±0.055	—	~1.00x	≈	37.9%	50
orderBy deep relation + scalar	0.937ms±0.108	0.767ms±0.088	—	~1.00x	≈	36.3%	50
distinct status	8.58ms±0.760	5.89ms±0.577	—	1.46x	***	29.9%	50
distinct multi	9.94ms±0.660	7.19ms±0.539	—	1.38x	***	24.1%	50
select + include	0.497ms±0.076	0.125ms±0.034	0.202ms	~1.00x	≈	72.4%	50
_count relation	0.725ms±0.129	0.533ms±0.111	—	~1.00x	≈	58.3%	50
_count multi-relation	0.103ms±0.108	0.055ms±0.034	—	~1.00x	≈	107.3%	50
_count inside include	0.963ms±0.118	0.501ms±0.096	—	~1.00x	≈	57.7%	50
_count inside nested select	1.54ms±0.156	0.840ms±0.095	—	~1.00x	≈	36.7%	50
_count deep include	1.39ms±0.118	0.976ms±0.066	—	~1.00x	≈	23.4%	50
findMany Date range	0.099ms±0.060	0.054ms±0.042	0.316ms	~1.00x	≈	128.0%	50
count Date range	0.478ms±0.157	0.410ms±0.109	0.338ms	~1.00x	≈	70.1%	50
findMany Date gte	0.091ms±0.0089	0.049ms±0.014	0.083ms	~1.00x	≈	76.3%	50
depth-1 low-fan Project→labels	0.123ms±0.017	0.069ms±0.019	—	~1.00x	≈	79.7%	50
depth-1 mid-fan Project→tasks	0.871ms±0.203	0.437ms±0.087	—	~1.00x	≈	54.0%	50
depth-1 high-fan User→assignedTasks	1.24ms±0.363	0.645ms±0.248	—	~1.00x	≈	94.6%	50
depth-1 wide	1.63ms±0.453	0.938ms±0.145	—	1.74x	***	50.3%	50
depth-1 no-limit Project→tasks	11.69ms±1.15	5.10ms±0.731	—	2.29x	***	40.4%	50
depth-2	0.906ms±0.194	0.544ms±0.050	—	~1.00x	≈	29.6%	50
depth-2 paginated	0.661ms±0.250	0.717ms±0.095	—	~1.00x	≈	40.5%	50
depth-2 high-fan	1.76ms±0.328	1.03ms±0.182	—	~1.00x	≈	51.6%	50
depth-2 wide+attach+activity	2.13ms±0.429	1.26ms±0.486	—	~1.00x	≈	95.4%	50
depth-2 no-limit	23.64ms±2.04	12.97ms±1.44	—	1.82x	***	38.2%	50
depth-3	5.23ms±0.329	2.79ms±0.696	—	1.88x	***	67.4%	50
depth-3 paginated	1.45ms±0.246	0.967ms±0.099	—	~1.00x	≈	33.0%	50
depth-4	3.22ms±0.295	1.78ms±0.430	—	1.81x	***	68.1%	50
depth-4 paginated	0.782ms±0.177	0.435ms±0.025	—	~1.00x	≈	19.1%	50
findFirst depth-2	0.538ms±0.060	0.330ms±0.053	—	~1.00x	≈	45.5%	50
findUnique depth-2	0.550ms±0.306	0.358ms±0.071	—	~1.00x	≈	57.1%	50

*** p < 0.001** p < 0.01* p < 0.05ns non significatif≈ dans le seuil de bruit de 1 ms± IC à 95 %CV% > 15% = forte variance

Voir les données brutes des benchmarks sur GitHub →

Méthodologie

–Pour reproduire : npm run bench (BENCHMARK_JSON_OUTPUT=1 écrit le JSON). Les résultats sont enregistrés dans benchmark-results/summary-.json ; v--latest.json alimente cette page.
–Chaque requête s’exécute sur la même base de données pour tous les clients : Prisma, prisma-sql, Drizzle. La taille d’échantillon par test figure dans la colonne n.
–Rapporté pour chaque côté : mean, median, stdDev, p95, p99, CV%. La significativité repose sur le test t de Welch avec un seuil pratique de 1 ms ; les barres d’erreur sont des IC à 95 %.
–Mode runtime mesuré : le SQL est converti à chaque appel. Les requêtes prérendues (@optimize) évitent entièrement la conversion et sont plus rapides que ce qui est affiché.
–Le matériel et les versions varient d’un run à l’autre - chaque fichier JSON porte son propre horodatage. Comparez des runs effectués sur la même machine.

Ce qui s’exécute plus vite, et ce qui reste dans Prisma

Chaque fonctionnalité de Prisma Client que nous avons vérifiée, sur PostgreSQL et SQLite. Les écritures restent dans Prisma ; les lectures sont compilées en SQL lorsque la forme est prise en charge.

PostgreSQL

SQLite

Méthodes de modèleOptions de requêteFiltresTriAgrégatsAPI clientTypes de résultat

25 des 73 fonctionnalités vérifiées sont entièrement accélérées sur PostgreSQL. 19 peuvent renvoyer un résultat différent de Prisma ; la carte complète les liste une par une avec la raison.

Nombre de fonctionnalités par statut
Statut	PostgreSQL	SQLite
Accéléré	25	21
Partiel	6	6
Repli sur Prisma	9	7
Exécuté par Prisma	7	7
Peut différer	19	17
Non disponible	2	4
prisma-sql uniquement	5	2
Absent de Prisma	0	6
Non vérifié	0	3

Ouvrir la carte de parité complète

ValidéComment garantissons-nous la correction ?Les requêtes prises en charge sont validées contre Prisma sur PostgreSQL et SQLite, avec des rapports de benchmark couvrant Prisma v6, v7, v8, Drizzle et le SQL généré.Voir la méthodologie de test

Comment elle optimise Prisma

Contournez le chemin d’exécution de lecture de Prisma tout en conservant l’API et les types Prisma

Intercepter les requêtes Prisma

L’extension intercepte les opérations de lecture (findMany, findFirst, findUnique, count, aggregate, groupBy) avant leur exécution

generated/sql, extrait

query: {
  $allModels: {
    async $allOperations({ model, operation, args, query }) {
      if (!ACCELERATED_METHODS.has(operation)) {
        return query(args)
      }
      return executeAccelerated(model, operation, args, query)
    },
  },
}

Générer du SQL optimisé

Convertir les requêtes Prisma en SQL rapide et paramétré avec des JOIN optimisés

SQL pour PostgreSQL

SELECT user_t.id, user_t.email, user_t.status,
  COALESCE((
    SELECT COALESCE(json_agg(json_build_object(
      'id', posts_0.id,
      'title', posts_0.title,
      'authorId', posts_0."authorId"
    )), '[]'::json)
    FROM "public"."Post" posts_0
    WHERE posts_0."authorId" = user_t.id
  ), '[]'::json) AS posts
FROM "public"."User" user_t
WHERE user_t.status = $1

-- params ["ACTIVE"]

Exécuter directement

Exécuter les requêtes via postgres.js ou better-sqlite3 en contournant l’overhead de lecture de Prisma

generated/sql, extrait

if (DIALECT === 'postgres') {
  await client.unsafe(sql, normalizedParams).forEach((row) => {
    results.push(row)
  })
  return results
}

const stmt = getOrPrepareStatement(client, sql)
return stmt.all(...normalizedParams)

Renvoyer des résultats compatibles

Les résultats correspondent au format attendu par Prisma. Types, IntelliSense et code de requête existant restent inchangés

users.ts

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

users[0].email
users[0].posts[0].title

// Mêmes types inférés que Prisma Client.
// Les valeurs Decimal, BigInt et DateTime peuvent
// différer ; la carte de parité liste chaque cas.

generated/sql, extrait

query: {
  $allModels: {
    async $allOperations({ model, operation, args, query }) {
      if (!ACCELERATED_METHODS.has(operation)) {
        return query(args)
      }
      return executeAccelerated(model, operation, args, query)
    },
  },
}

SELECT user_t.id, user_t.email, user_t.status,
  COALESCE((
    SELECT COALESCE(json_agg(json_build_object(
      'id', posts_0.id,
      'title', posts_0.title,
      'authorId', posts_0."authorId"
    )), '[]'::json)
    FROM "public"."Post" posts_0
    WHERE posts_0."authorId" = user_t.id
  ), '[]'::json) AS posts
FROM "public"."User" user_t
WHERE user_t.status = $1

-- params ["ACTIVE"]

if (DIALECT === 'postgres') {
  await client.unsafe(sql, normalizedParams).forEach((row) => {
    results.push(row)
  })
  return results
}

const stmt = getOrPrepareStatement(client, sql)
return stmt.all(...normalizedParams)

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

users[0].email
users[0].posts[0].title

// Mêmes types inférés que Prisma Client.
// Les valeurs Decimal, BigInt et DateTime peuvent
// différer ; la carte de parité liste chaque cas.

Sécurité vérifiéeComment prévenons-nous l’injection SQL ?Validation multi-couches avec liaison de paramètres, vérifications de champs basées sur le schéma et la suite de tests de sécurité actuelleVoir les détails sécurité

Pourquoi choisir cette extension Prisma ?

Obtenez la vitesse d’exécution du SQL brut en lecture tout en conservant l’expérience développeur de Prisma

Accélération Prisma instantanée: Une configuration unique accélère les lectures Prisma. Pas de refactor, pas de migration, pas d’arrêt.
Conservez vos types Prisma: Support TypeScript complet. Inférence de types, autocomplétion et sécurité à la compilation préservées tout en accélérant les lectures.
Solution testée en production: Les tests de parité actuels valident les lectures prises en charge sur les versions récentes de Prisma. Utilisez-la pour des applications en production après avoir vérifié la compatibilité avec votre version de Prisma et votre workload.
Support multi-bases: Optimisez les lectures Prisma sur PostgreSQL (dont Neon, Supabase) et SQLite.
Option précompilée: Un générateur optionnel crée le SQL au build, réduisant l’overhead à quelques microsecondes pour vos requêtes les plus chaudes.
Prête pour le serverless (runtimes Node): Fonctionne dans les runtimes Node serverless. Le support des runtimes Edge dépend des contraintes du runtime et du driver utilisé.

Au-delà des lectures plus rapides

prisma-sql ajoute des capacités absentes de Prisma Client. Mêmes types, même style de code.

$batch

N requêtes de dashboard, un seul aller-retour

Regroupez des lectures indépendantes en un seul aller-retour PostgreSQL. Résultat objet typé, sans jongler avec Promise.all.

const dash = await prisma.$batch((b) => ({
  users: b.user.count(),
  posts: b.post.findMany({ take: 10 }),
  stats: b.task.aggregate({ _count: true }),
}))

@optimize

Précalculez vos requêtes les plus chaudes

Annotez un modèle dans schema.prisma. À la génération, le SQL exact est figé ; les formes de requête correspondantes au runtime évitent complètement la conversion.

/// @optimize {
///   "method": "findMany",
///   "query": {
///     "where": { "status": "$status" },
///     "take": "$take"
///   }
/// }
model User { ... }

Planificateur de cardinalité

Une stratégie choisie par les données, pas au hasard

Les statistiques de relations collectées pilotent le choix de stratégie entre jointures plates, sous-requêtes corrélées et chargement segmenté par where-in. Les grandes tables enfants ne déclenchent jamais de scans par parent.

prisma-sql-collect-stats \
  --output dist/planner.generated.js \
  --prisma-client dist/client/index.js

Quand la performance Prisma compte le plus

Scénarios courants où cette extension fait une vraie différence

Analytics et reporting

Les agrégations et opérations groupBy Prisma bénéficient fortement de l’exécution SQL directe

groupBy 5× plus rapide accélère les rapports
Requêtes d’agrégation plus rapides
Métriques temps réel avec une latence plus faible

APIs à fort trafic

L’overhead par requête se cumule sous charge, surtout sur les endpoints dominés par la lecture

Temps de réponse API plus faibles
Plus de requêtes par instance
Coûts d’infrastructure réduits

Fonctions serverless

Chaque milliseconde compte en serverless : réduisez la latence de lecture là où c’est critique

Meilleurs p95/p99 en lecture
Coûts plus bas grâce à des lectures plus rapides
Lectures plus rapides sans refactor

Backends mobiles

Les utilisateurs perçoivent la latence : des lectures plus rapides améliorent immédiatement l’UX perçue

Chargement du feed plus rapide
Pagination plus rapide
Interactions plus réactives

Optimisez Prisma en 3 étapes

Accélérez les lectures Prisma en moins de 60 secondes

Installer l’extension Prisma

Terminal

# PostgreSQL
npm install prisma-sql postgres

# SQLite
npm install prisma-sql better-sqlite3

Ajouter l’extension au Prisma Client

schema.prisma

generator client {
  provider = "prisma-client"
}

generator sql {
  provider = "prisma-sql-generator"
}

Terminal

npx prisma generate

db.ts

import { PrismaClient } from '@prisma/client'
import { speedExtension, type SpeedClient } from './generated/sql'
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL!)
const basePrisma = new PrismaClient()

export const prisma = basePrisma.$extends(
  speedExtension({ postgres: sql }),
) as SpeedClient<typeof basePrisma>

Utiliser Prisma normalement

users.ts

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

SQLite : passez speedExtension({ sqlite: db }) avec une base de données better-sqlite3.Guide d’installation complet

FAQ performance Prisma

Questions fréquentes sur l’optimisation des lectures Prisma

Pourquoi Prisma a-t-il un overhead ?

Prisma ajoute un overhead car il implémente des garanties d’API comme la validation basée sur le schéma, un comportement de requête cohérent et la mise en forme des résultats. Ces couches offrent une excellente expérience développeur mais coûtent du temps comparé à l’exécution directe de SQL brut.

Comment optimiser des requêtes Prisma ?

Optimisez les workloads Prisma dominés par la lecture en ajoutant cette extension. Elle exécute les opérations de lecture via du SQL direct avec postgres.js ou better-sqlite3 tout en conservant l’API et les types Prisma. Le setup est un petit changement d’initialisation et ne nécessite pas de refactor de vos requêtes existantes.

Prisma est-il plus lent que le SQL brut ?

Pour de nombreux workloads en lecture, oui. Il y a un overhead architectural par rapport à l’exécution de SQL brut. Cette extension vise à conserver le DX de Prisma tout en réduisant la latence de lecture via l’exécution directe de SQL.

Puis-je accélérer Prisma sans modifier mes requêtes existantes ?

Oui. Ajoutez l’extension une fois lors de l’initialisation du Prisma Client et gardez votre code de requêtes Prisma inchangé. Les lectures s’exécutent plus vite, tandis que l’API, les types et le schéma Prisma restent identiques.

Est-ce que ça marche en production ?

Oui, l’extension est conçue pour un usage en production sur les chemins de lecture pris en charge. Vérifiez toujours la compatibilité avec votre version de Prisma et exécutez vos propres tests de régression avant déploiement.

Qu’est-ce qui rend les agrégations Prisma plus lentes ?

Les agrégations et groupBy amplifient souvent l’overhead fixe (traitement des requêtes et mise en forme des résultats) et peuvent impliquer de plus grands jeux de résultats intermédiaires. Cette extension optimise ces lectures en générant du SQL directement, ce qui réduit généralement la latence sur les endpoints riches en agrégations.

Prêt à accélérer Prisma ?

Consultez le tableau de benchmarks actuel pour les lectures PostgreSQL et SQLite prises en charge

Installer Prisma-SQL Voir sur GitHub

Corrigez les requêtes Prisma lentes grâce à l’exécution SQL directe

Pourquoi Prisma est-il lent ?

Le parcours de Prisma : le DX d’abord, la performance compte à l’échelle

💡 Pourquoi cette extension existe

🎯 2019 : La naissance de Prisma moderne

⚡ 2020–2022 : Croissance rapide et expansion des fonctionnalités

📊 2023 : L’overhead devient visible à l’échelle

🚀 2024–2025 : Le travail performance de Prisma continue

🎯 2026 : Sortie de l’extension prisma-sql

Couche de traduction des requêtes

Validation et garanties de type

Mise en forme des résultats

À quelle vitesse ? Benchmarks réels

Résultats détaillés des benchmarks

PostgreSQLPrisma v6 (6.19.3)

PostgreSQLPrisma v7 (7.10.0)

PostgreSQLPrisma v8 (8.1.0-dev.1)

SQLitePrisma v6 (6.19.3)

SQLitePrisma v7 (7.10.0)

SQLitePrisma v8 (8.1.0-dev.1)

Méthodologie

Ce qui s’exécute plus vite, et ce qui reste dans Prisma

Comment elle optimise Prisma

Intercepter les requêtes Prisma

Générer du SQL optimisé

Exécuter directement

Renvoyer des résultats compatibles

Pourquoi choisir cette extension Prisma ?

Au-delà des lectures plus rapides

$batch

@optimize

Planificateur de cardinalité

Quand la performance Prisma compte le plus

Analytics et reporting

APIs à fort trafic

Fonctions serverless

Backends mobiles

Optimisez Prisma en 3 étapes

Installer l’extension Prisma

Ajouter l’extension au Prisma Client

Utiliser Prisma normalement

FAQ performance Prisma

Prêt à accélérer Prisma ?