🚀 A Solução para Prisma Lento

Corrija Consultas Prisma Lentas
Deixe sua API 2–7× Mais Rápida (Até 53,5×)

O Prisma está lento? Você não está sozinho. Gosta do DX do Prisma, mas precisa de mais performance? Acelere consultas Prisma lentas em 2–7× (até 53,5× em filtros de relação no SQLite) sem alterar nenhuma consulta existente.

Acelerar Prisma Agora Ver Como Funciona
Leituras Prisma Mais Rápidas
Sem Mudanças nas Consultas
Pronto para Produção
137 Testes E2E
Corrija Prisma lento em uma linha 
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×
Leituras Prisma Mais Rápidas
Aceleração típica
0
Mudanças nas Consultas
Mantenha suas chamadas Prisma atuais
137
Testes E2E
Solução verificada
100%
Segurança de Tipos
Mesma API do Prisma

Por que o Prisma é lento?

Entender a evolução do Prisma e suas características de performance ajuda a explicar por que esta extensão existe.

A Jornada do Prisma: DX Primeiro, Performance Importa em Escala

🎯 2019: O Nascimento do Prisma Moderno

O Prisma 2 foi lançado em 2019, mudando o cenário de ORMs em TypeScript com acesso ao banco com segurança de tipos e tipos gerados a partir do seu schema. O Prisma introduziu uma arquitetura baseada em engine para traduzir consultas, validá-las e fornecer garantias fortes que eram difíceis de alcançar com ORMs JavaScript tradicionais.

⚡ 2020–2022: Crescimento Rápido e Expansão de Recursos

O Prisma adicionou recursos poderosos como nested writes, transações e middleware. O conjunto de recursos cresceu, mas cada consulta ainda pagava um custo arquitetural: consultas são representadas, validadas, executadas e os resultados são moldados para corresponder à API do Prisma.

📊 2023: Overhead Fica Notável em Escala

À medida que mais equipes implantaram o Prisma em workloads de alto tráfego, o overhead fixo por consulta tornou-se mensurável. Isso aparece principalmente em endpoints com muitas leituras, analytics, agregações e grandes conjuntos de resultados. O overhead não é um bug; é o custo das garantias e do comportamento da API do Prisma.

🚀 2024–2025: O Trabalho de Performance do Prisma Continua

O Prisma entregou grandes atualizações focadas em performance e mudanças na engine. Mesmo com melhorias, ainda existe um custo inevitável de parsing, validação, planejamento e formatação de resultados em comparação com executar SQL bruto diretamente.

🎯 2026: Extensão prisma-sql Lançada

Esta extensão foca em performance de leitura. Ela contorna o caminho de execução de leitura do Prisma para findMany, findFirst, findUnique, count, aggregate e groupBy, mantendo o Prisma para writes, migrations, gerenciamento de schema e geração de tipos. Valide compatibilidade com sua versão do Prisma antes do rollout.

💡 Por que Esta Extensão Existe

O Prisma fez escolhas arquiteturais corretas para seus objetivos: segurança de tipos, experiência do desenvolvedor e comportamento consistente entre bancos. Mas essas escolhas criam overhead que fica perceptível em escala. Esta extensão não substitui o Prisma — ela otimiza leituras para equipes que querem o DX do Prisma com execução mais rápida onde importa.

Camada de Tradução de Consultas

O Prisma traduz os inputs da sua consulta para SQL específico do banco. Isso habilita comportamento cross-database e a semântica da API do Prisma, mas adiciona tempo de processamento antes de o banco ver o SQL.

Validação e Garantias de Tipo

O Prisma valida consultas contra o schema e impõe garantias no nível da API. Esses mecanismos evitam classes de bugs, mas também adicionam overhead a cada consulta.

Formatação de Resultados

Os resultados são moldados para corresponder ao comportamento da API do Prisma. Isso é ótimo para DX e consistência, mas adiciona latência, especialmente em grandes conjuntos de resultados e includes complexos.

Esta extensão complementa o Prisma oferecendo um caminho mais rápido para consultas de leitura. Você mantém tudo o que gosta no Prisma e obtém leituras 2–7× mais rápidas em casos típicos (e até 53,5× em filtros de relação no SQLite) quando performance importa.

Quanto mais rápido? Benchmarks reais

Comparação abrangente entre Prisma v6, v7, Drizzle ORM e Prisma-SQL

Ambiente de benchmark: MacBook Pro M1 • PostgreSQL 15 • SQLite 3.43 • 137 casos de teste por banco de dados

PostgreSQL

Média em 57 casos de teste

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 relação
vs Prisma v6 ("none"-filtro)

SQLite

Média em 56 casos de teste

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 relação
vs Prisma v6 ("none"-filtro)

Benchmarks based on 137 E2E tests per database. Prisma v6.16.3, Prisma v7.2.0, Drizzle ORM latest. Ver dados completos do benchmark →

Resultados detalhados de benchmark

Comparação estatística com o teste t de Welch e um limite de significância prática de 1 ms

Estes resultados refletem o modo de execução, onde as consultas são convertidas para SQL a cada requisição. No modo pré-renderizado, o SQL é gerado em tempo de build — em tempo de execução são executadas consultas parametrizadas brutas sem qualquer sobrecarga de conversão.

PostgreSQL Prisma v6

Média 2.07x vs Prisma Média 1.68x vs Drizzle 28/95 vitórias estatisticamente significativas 65 dentro do limite de ruído
Mar 7, 2026
Teste Prisma prisma-sql Drizzle Aceleração 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 não significativo ≈ dentro do limite de ruído de 1 ms ± IC de 95% CV% > 15% = alta variância
Modo de execução avaliado. O modo pré-renderizado ignora completamente a conversão de consulta para SQL em tempo de execução — espere latência menor do que a mostrada aqui, especialmente para consultas complexas onde o custo de conversão é proporcionalmente maior.
Ver dados brutos de benchmark no GitHub →
✓ Validado

Como garantimos correção?

Cada consulta é validada contra o Prisma com 137 testes end-to-end em PostgreSQL e SQLite

Ver Metodologia de Testes →

Como Ela Otimiza o Prisma

Contorne o caminho de execução de leitura do Prisma mantendo a API e os tipos do Prisma

1

Interceptar Consultas do Prisma

A extensão captura operações de leitura (findMany, findFirst, findUnique, count, aggregate, groupBy) antes de executar

2

Gerar SQL Otimizado

Converter consultas Prisma em SQL rápido e parametrizado com JOINs otimizados

3

Executar Diretamente

Rodar consultas via postgres.js ou better-sqlite3, contornando o overhead de leitura do Prisma

4

Retornar Resultados Compatíveis

Os resultados correspondem ao formato esperado pelo Prisma. Tipos, IntelliSense e o código de consulta existente permanecem inalterados

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
🔒 Segurança Verificada

Como evitamos SQL injection?

Validação em múltiplas camadas com parameter binding, checagem de campos baseada em schema e 137 testes de segurança (suíte atual)

Ver Detalhes de Segurança →

Por que Escolher Esta Extensão para Prisma?

Obtenha velocidade de execução de SQL bruto para leituras mantendo a experiência do desenvolvedor do Prisma

Aceleração Instantânea do Prisma

Configuração única acelera leituras do Prisma. Sem refatoração, sem migração, sem downtime.

Mantenha Seus Tipos do Prisma

Suporte completo a TypeScript mantido. Inferência de tipos, autocomplete e segurança em tempo de compilação preservados enquanto as leituras aceleram.

Solução Testada em Produção

137 testes E2E validam compatibilidade com versões recentes do Prisma. Usada para acelerar leituras do Prisma em apps de produção.

Suporte a Múltiplos Bancos

Otimize leituras do Prisma em PostgreSQL (incluindo Neon, Supabase) e SQLite.

Opção Pré-Compilada

Gerador opcional cria SQL em build-time, reduzindo overhead a microssegundos para suas consultas mais críticas.

Pronto para Serverless (Runtimes Node)

Funciona em runtimes serverless Node. Suporte ao Edge runtime depende de restrições do runtime e do driver usado.

Quando a Performance do Prisma Importa Mais

Cenários comuns em que esta extensão faz diferença de verdade

📊 Analytics e Relatórios

Agregações e operações groupBy do Prisma se beneficiam significativamente da execução direta de SQL

  • groupBy 5× mais rápido acelera relatórios
  • Consultas aggregate mais rápidas
  • Métricas em tempo real com menor latência

🚀 APIs de Alto Tráfego

O overhead por consulta se acumula sob carga, especialmente em endpoints com muitas leituras

  • Menores tempos de resposta da API
  • Mais requisições por instância
  • Redução de custos de infraestrutura

☁️ Funções Serverless

Cada milissegundo importa em serverless: reduza latência de leitura onde conta

  • Melhor p95/p99 em leituras
  • Menores custos com leituras mais rápidas
  • Leituras mais rápidas sem refatorar

📱 Backends Mobile

Usuários percebem latência: leituras mais rápidas melhoram o UX percebido imediatamente

  • Carregamento de feed mais rápido
  • Paginação mais rápida
  • Interações mais responsivas

Otimize o Prisma em 3 Passos

Acelere leituras do Prisma em menos de 60 segundos

① Instalar a Extensão do Prisma 

# PostgreSQL
npm install prisma-sql postgres

# SQLite
npm install prisma-sql better-sqlite3

② Adicionar a Extensão ao 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 })
)

③ Usar o Prisma Normalmente 

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

FAQ de Performance do Prisma

Perguntas comuns sobre otimizar leituras do Prisma

Por que o Prisma tem overhead?

O Prisma adiciona overhead porque implementa garantias de API como validação baseada em schema, comportamento consistente de consulta e formatação de resultados. Essas camadas dão uma ótima experiência de desenvolvedor, mas custam tempo em comparação com executar SQL bruto diretamente.

Como otimizo consultas do Prisma?

Otimize workloads Prisma com muitas leituras adicionando esta extensão. Ela executa leituras via SQL direto usando postgres.js ou better-sqlite3 mantendo a API e os tipos do Prisma. O setup é uma pequena mudança de inicialização e não exige refatoração das consultas existentes.

O Prisma é mais lento que SQL bruto?

Para muitos workloads de leitura, sim. Existe overhead arquitetural em comparação com execução de SQL bruto. Esta extensão busca manter o DX do Prisma reduzindo latência de leitura ao executar SQL diretamente.

Posso acelerar o Prisma sem mudar consultas existentes?

Sim. Adicione a extensão uma vez durante a inicialização do Prisma Client e mantenha seu código de consulta Prisma inalterado. As leituras ficam mais rápidas enquanto API, tipos e schema permanecem iguais.

Isso funciona em produção?

Sim. É validado com 137 testes E2E e projetado para uso em produção. Sempre verifique compatibilidade com sua versão do Prisma e rode seus próprios testes de regressão antes do rollout.

O que causa agregações mais lentas no Prisma?

Agregações e groupBy frequentemente amplificam overhead fixo (processamento de consulta e formatação de resultados) e podem envolver conjuntos intermediários maiores. Esta extensão otimiza essas leituras gerando SQL diretamente, o que geralmente reduz latência em endpoints com muitas agregações.

Pronto para Acelerar o Prisma?

Junte-se a devs otimizando leituras do Prisma: 2–7× mais rápido (até 53,5×)

Instalar Prisma-SQL Ver no GitHub