🚀 La solution pour Prisma lent

Corrigez les requêtes Prisma lentes
Rendez votre API 2–7× plus rapide (jusqu’à 53,5×)

Prisma est lent ? Vous n’êtes pas seul. Vous aimez le DX de Prisma mais vous avez besoin de meilleures performances ? Accélérez les requêtes Prisma lentes de 2–7× (jusqu’à 53,5× sur les filtres de relation SQLite) sans modifier aucune requête existante.

Accélérer Prisma maintenant Voir comment ça marche
Lectures Prisma plus rapides
Aucun changement de requête
Prêt pour la production
137 tests E2E
Corriger Prisma lent en une ligne 
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×
Lectures Prisma plus rapides
Accélération typique
0
Changements de requête
Conservez vos appels Prisma existants
137
Tests E2E
Solution vérifiée
100%
Sécurité des types
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 : d’abord le DX, puis la performance à l’échelle

🎯 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 et valider les requêtes, et fournir des garanties 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.

💡 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.

Couche de traduction des requêtes

Prisma traduit les entrées de requête en SQL spécifique au moteur. 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. Vous gardez tout ce que vous aimez dans Prisma tout en obtenant des lectures 2–7× plus rapides dans les cas typiques (et jusqu’à 53,5× sur les filtres de relation SQLite) quand la performance compte.

À quelle vitesse ? Benchmarks réels

Comparaison complète entre Prisma v6, v7, Drizzle ORM et Prisma-SQL

Environnement de benchmark : MacBook Pro M1 • PostgreSQL 15 • SQLite 3.43 • 137 cas de test par base de données

PostgreSQL

Moyenne sur 57 cas de test

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×
Requêtes DISTINCT
vs Prisma v6
5.5×
Filtres de relations
vs Prisma v6 ("none"-filtre)

SQLite

Moyenne sur 56 cas de test

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×
Requêtes simples
vs Prisma v6
69.7×
Filtres de relations
vs Prisma v6 ("none"-filtre)

Benchmarks basés sur 137 tests E2E par base de données. Prisma v6.16.3, Prisma v7.2.0, Drizzle ORM latest. 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 d’exécution, où les requêtes sont converties en SQL à chaque demande. En mode pré-généré, le SQL est généré au moment de la compilation — l’exécution lance des requêtes paramétrées brutes sans aucun coût de conversion.

PostgreSQL Prisma v6

Moyenne 2.07x vs Prisma Moyenne 1.68x vs Drizzle 28/95 gains statistiquement significatifs 65 dans le seuil de bruit
Mar 7, 2026
Test Prisma prisma-sql Drizzle Accélération 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 non significatif ≈ dans le seuil de bruit de 1 ms ± IC à 95 % CV% > 15% = forte variance
Mode d’exécution évalué. Le mode pré-généré ignore totalement la conversion requête-vers-SQL à l’exécution — 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é.
Voir les données brutes des benchmarks sur GitHub →
✓ Validé

Comment garantissons-nous la correction ?

Chaque requête est validée contre Prisma avec 137 tests end-to-end sur PostgreSQL et SQLite

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

1

Intercepter les requêtes Prisma

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

2

Générer du SQL optimisé

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

3

Exécuter directement

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

4

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

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
🔒 Sécurisé et vérifié

Comment prévenir l’injection SQL ?

Validation multi-couches avec liaison de paramètres, vérifications basées sur le schéma et 137 tests sécurité (suite actuelle)

Voir les détails sécurité →

Pourquoi choisir cette extension Prisma ?

Obtenez la vitesse d’exécution 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, autocomplétion et sécurité à la compilation préservées tout en accélérant les lectures.

Solution testée en production

137 tests E2E valident la compatibilité avec les versions récentes de Prisma. Utilisée pour accélérer les lectures Prisma en production.

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 du SQL au build, réduisant l’overhead à des microsecondes pour vos requêtes les plus chaudes.

Prête pour le serverless (runtimes Node)

Fonctionne dans des runtimes Node serverless. Le support Edge runtime dépend des contraintes du runtime et du driver utilisé.

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 

# PostgreSQL
npm install prisma-sql postgres

# SQLite
npm install prisma-sql better-sqlite3

② Ajouter l’extension au 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 })
)

③ Utiliser Prisma normalement 

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

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. C’est validé par 137 tests E2E et conçu pour un usage en production. 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 ?

Rejoignez les développeurs qui optimisent les lectures Prisma : 2–7× plus rapide (jusqu’à 53,5×)

Installer Prisma-SQL Voir sur GitHub