🚀 La solución para Prisma lento

Arregla consultas lentas de Prisma
Haz tu API 2–7× más rápida (hasta 53.5×)

¿Prisma va lento? No estás solo. ¿Te encanta el DX de Prisma pero necesitas mejor rendimiento? Acelera consultas lentas de Prisma 2–7× (hasta 53.5× en filtros de relación de SQLite) sin cambiar ninguna consulta existente.

Acelerar Prisma ahora Ver cómo funciona
Lecturas de Prisma más rápidas
Sin cambios de consulta
Listo para producción
137 pruebas E2E
Arregla Prisma lento en una línea 
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×
Lecturas de Prisma más rápidas
Aceleración típica
0
Cambios de consulta
Mantén tus llamadas Prisma existentes
137
Pruebas E2E
Solución verificada
100%
Seguridad de tipos
La misma API de Prisma

¿Por qué Prisma es lento?

Entender la evolución de Prisma y sus características de rendimiento ayuda a explicar por qué existe esta extensión.

El recorrido de Prisma: DX primero, el rendimiento importa a escala

🎯 2019: El nacimiento de Prisma moderno

Prisma 2 se lanzó en 2019, cambiando el panorama de ORMs en TypeScript con acceso a base de datos con seguridad de tipos y tipos generados desde tu esquema. Prisma introdujo una arquitectura basada en engine para traducir consultas, validarlas y ofrecer garantías fuertes que eran difíciles de lograr con ORMs tradicionales de JavaScript.

⚡ 2020–2022: Crecimiento rápido y expansión de funcionalidades

Prisma añadió funciones potentes como escrituras anidadas, transacciones y middleware. El conjunto de funciones creció, pero cada consulta seguía pagando un coste arquitectónico: las consultas se representan, validan, ejecutan y los resultados se moldean para coincidir con la API de Prisma.

📊 2023: La sobrecarga se vuelve notable a escala

A medida que más equipos desplegaron Prisma en cargas de trabajo de alto tráfico, la sobrecarga fija por consulta se volvió medible. Esto se ve especialmente en endpoints con muchas lecturas, analítica, agregaciones y conjuntos de resultados grandes. La sobrecarga no es un bug; es el coste de las garantías y el comportamiento de la API de Prisma.

🚀 2024–2025: Continúa el trabajo de rendimiento en Prisma

Prisma publicó actualizaciones importantes centradas en rendimiento y cambios del engine. Incluso con mejoras, sigue existiendo un coste inevitable por parsear, validar, planificar y moldear resultados frente a ejecutar SQL crudo directamente.

🎯 2026: Se lanza la extensión prisma-sql

Esta extensión se centra en el rendimiento de lectura. Evita la ruta de ejecución de lecturas de Prisma para findMany, findFirst, findUnique, count, aggregate y groupBy, mientras mantiene Prisma para escrituras, migraciones, gestión de esquema y generación de tipos. Valida la compatibilidad con tu versión de Prisma antes del despliegue.

💡 Por qué existe esta extensión

Prisma tomó las decisiones arquitectónicas correctas para sus objetivos: seguridad de tipos, experiencia de desarrollo y comportamiento consistente entre bases de datos. Pero esas decisiones crean una sobrecarga que se nota a escala. Esta extensión no reemplaza Prisma: optimiza lecturas para equipos que quieren el DX de Prisma más ejecución más rápida donde importa.

Capa de traducción de consultas

Prisma traduce los inputs de tu consulta a SQL específico del motor. Esto permite comportamiento consistente entre bases de datos y la semántica de la API de Prisma, pero añade tiempo de procesamiento antes de que la base de datos vea el SQL.

Validación y garantías de tipos

Prisma valida consultas contra el esquema y aplica garantías a nivel de API. Estas salvaguardas previenen clases de bugs, pero también añaden sobrecarga a cada consulta.

Moldeado de resultados

Los resultados se moldean para coincidir con el comportamiento esperado de la API de Prisma. Esto es excelente para DX y consistencia, pero añade latencia, especialmente en conjuntos de resultados grandes e includes complejos.

Esta extensión complementa Prisma ofreciendo una ruta más rápida para consultas de lectura. Conservas todo lo que te gusta de Prisma y obtienes lecturas 2–7× más rápidas en casos típicos (y hasta 53.5× en filtros de relación de SQLite) cuando el rendimiento importa.

¿Cuánto más rápido? Benchmarks reales

Comparación completa entre Prisma v6, v7, Drizzle ORM y Prisma-SQL

Entorno de benchmark: MacBook Pro M1 • PostgreSQL 15 • SQLite 3.43 • 137 casos de prueba por base de datos

PostgreSQL

Promedio en 57 casos de prueba

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×
Consultas DISTINCT
vs Prisma v6
5.5×
Filtros de relaciones
vs Prisma v6 ("none"-filtro)

SQLite

Promedio en 56 casos de prueba

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×
Consultas simples
vs Prisma v6
69.7×
Filtros de relaciones
vs Prisma v6 ("none"-filtro)

Benchmarks basados en 137 pruebas E2E por base de datos. Prisma v6.16.3, Prisma v7.2.0, Drizzle ORM latest. Ver datos completos del benchmark →

Resultados detallados de benchmark

Comparación estadística con la prueba t de Welch y un umbral de significancia práctica de 1 ms

Estos resultados reflejan el modo de ejecución, donde las consultas se convierten a SQL en cada solicitud. En el modo preprocesado, el SQL se genera en tiempo de compilación — el tiempo de ejecución ejecuta consultas parametrizadas en bruto sin sobrecarga de conversión.

PostgreSQL Prisma v6

Promedio 2.07x frente a Prisma Promedio 1.68x frente a Drizzle 28/95 victorias estadísticamente significativas 65 dentro del umbral de ruido
Mar 7, 2026
Prueba Prisma prisma-sql Drizzle Aceleración 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 no significativo ≈ dentro del umbral de ruido de 1 ms ± IC del 95% CV% > 15% = alta variación
Modo de ejecución evaluado. El modo preprocesado omite por completo la conversión de consulta a SQL en tiempo de ejecución — se espera una latencia menor que la mostrada aquí, especialmente para consultas complejas donde el costo de conversión es proporcionalmente mayor.
Ver datos brutos de benchmark en GitHub →
✓ Validado

¿Cómo aseguramos la corrección?

Cada consulta se valida contra Prisma con 137 pruebas end-to-end en PostgreSQL y SQLite

Ver metodología de pruebas →

Cómo optimiza Prisma

Evita la ruta de ejecución de lecturas de Prisma manteniendo la API y los tipos de Prisma

1

Interceptar consultas de Prisma

La extensión captura operaciones de lectura (findMany, findFirst, findUnique, count, aggregate, groupBy) antes de que se ejecuten

2

Generar SQL optimizado

Convierte consultas Prisma en SQL rápido y parametrizado con JOINs optimizados

3

Ejecutar directamente

Ejecuta consultas mediante postgres.js o better-sqlite3, evitando la sobrecarga de lectura de Prisma

4

Devolver resultados compatibles

Los resultados coinciden con la forma esperada por Prisma. Tipos, IntelliSense y el código de consultas existente permanecen sin cambios

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
🔒 Seguridad verificada

¿Cómo prevenimos inyección SQL?

Validación multi-capa con enlace de parámetros, chequeos de campos basados en esquema y 137 pruebas de seguridad (suite actual)

Ver detalles de seguridad →

¿Por qué elegir esta extensión de Prisma?

Obtén velocidad de ejecución de SQL crudo para lecturas manteniendo la experiencia de desarrollo de Prisma

Aceleración instantánea de Prisma

Una configuración única acelera lecturas de Prisma. Sin refactor, sin migración, sin downtime.

Mantén tus tipos de Prisma

Compatibilidad completa con TypeScript. Inferencia de tipos, autocompletado y seguridad en compilación preservados mientras se aceleran lecturas.

Solución probada en producción

137 pruebas E2E validan compatibilidad con versiones recientes de Prisma. Usada para acelerar lecturas de Prisma en apps de producción.

Soporte para múltiples bases de datos

Optimiza lecturas de Prisma en PostgreSQL (incluido Neon, Supabase) y SQLite.

Opción precompilada

Un generador opcional crea SQL en build-time, reduciendo la sobrecarga a microsegundos para tus consultas más calientes.

Listo para serverless (runtimes Node)

Funciona en runtimes serverless de Node. El soporte para Edge runtime depende de las restricciones del runtime y del driver que uses.

Cuándo el rendimiento de Prisma importa más

Escenarios comunes donde esta extensión marca una diferencia real

📊 Analítica e informes

Las agregaciones y operaciones groupBy de Prisma se benefician significativamente de la ejecución SQL directa

  • groupBy 5× más rápido acelera informes
  • Consultas aggregate más rápidas
  • Métricas en tiempo real con menor latencia

🚀 APIs de alto tráfico

La sobrecarga por consulta se acumula bajo carga, especialmente en endpoints con muchas lecturas

  • Menores tiempos de respuesta de la API
  • Manejar más solicitudes por instancia
  • Reducir costos de infraestructura

☁️ Funciones serverless

Cada milisegundo cuenta en serverless: reduce latencia de lectura donde importa

  • Mejor p95/p99 en lecturas
  • Menor costo mediante lecturas más rápidas
  • Lecturas más rápidas sin refactors

📱 Backends móviles

Los usuarios notan la latencia: lecturas más rápidas mejoran el UX percibido de inmediato

  • Carga de feed más rápida
  • Paginación más rápida
  • Interacciones más responsivas

Optimiza Prisma en 3 pasos

Acelera lecturas de Prisma en menos de 60 segundos

① Instala la extensión de Prisma 

# PostgreSQL
npm install prisma-sql postgres

# SQLite
npm install prisma-sql better-sqlite3

② Añade la extensión al cliente de Prisma 

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 })
)

③ Usa Prisma normalmente 

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

FAQ de rendimiento de Prisma

Preguntas comunes sobre cómo optimizar lecturas en Prisma

¿Por qué Prisma tiene sobrecarga?

Prisma añade sobrecarga porque implementa garantías de API como validación basada en el esquema, comportamiento de consulta consistente y moldeado de resultados. Esas capas ofrecen una gran experiencia de desarrollo, pero cuestan tiempo comparado con ejecutar SQL crudo directamente.

¿Cómo optimizo consultas de Prisma?

Optimiza cargas de trabajo de Prisma centradas en lecturas añadiendo esta extensión. Ejecuta operaciones de lectura mediante SQL directo con postgres.js o better-sqlite3, manteniendo la API y los tipos de Prisma. La configuración es un pequeño cambio de inicialización y no requiere refactor de tus consultas existentes.

¿Prisma es más lento que SQL crudo?

Para muchas cargas de lectura, sí. Hay una sobrecarga arquitectónica frente a ejecutar SQL crudo. Esta extensión busca mantener el DX de Prisma reduciendo la latencia de lectura mediante ejecución SQL directa.

¿Puedo acelerar Prisma sin cambiar consultas existentes?

Sí. Añade la extensión una vez durante la inicialización del Prisma Client y mantén tu código de consultas Prisma sin cambios. Las operaciones de lectura se ejecutan más rápido mientras tu API, tipos y esquema de Prisma permanecen igual.

¿Esto funciona en producción?

Sí. Está validado con 137 pruebas E2E y está diseñado para usarse en producción. Verifica siempre la compatibilidad con tu versión de Prisma y ejecuta tus propias pruebas de regresión antes del despliegue.

¿Qué causa agregaciones más lentas en Prisma?

Las agregaciones y groupBy a menudo amplifican la sobrecarga fija (procesamiento de consulta y moldeado de resultados) y pueden involucrar conjuntos de resultados intermedios más grandes. Esta extensión optimiza esas lecturas generando SQL directamente, lo que típicamente reduce la latencia en endpoints con muchas agregaciones.

¿Listo para acelerar Prisma?

Únete a desarrolladores que optimizan lecturas de Prisma: 2–7× más rápido (hasta 53.5×)

Instalar Prisma-SQL Ver en GitHub