Prisma vs JDBC: el benchmark que casi me hace culpar al ORM equivocado

Hay una discusión que aparece cada vez que alguien postea un benchmark de ORM: "claro que JDBC es más rápido, estás midiendo la abstracción". Y tienen razón, pero solo a medias. Lo que nadie dice es que la abstracción no es el único culpable — a veces el culpable sos vos, que dejaste pasar un N+1 sin darte cuenta.

Armé prismavsjdbc para probar esto de forma controlada. No es un benchmark de quién gana. Es un laboratorio donde el mismo PostgreSQL 16, el mismo dataset de 50k tasks y los mismos casos de negocio corren contra dos stacks: Node.js 24 LTS + TypeScript + Prisma 5 por un lado, y Spring Boot 3 + Java 21 LTS + JdbcTemplate por el otro. El commit analizado es 2cd33e32bd29a1d4b46a26af0b56d6a912f5e4f5, tag best-effort-editorial-final.

La tesis que defiendo es esta: query shape, SQL/request y N+1 explican más que el slogan "ORM vs SQL directo". Cuando optimizás el shape, los dos stacks mejoran. Cuando no, los dos te cobran.

El problema que casi me hace concluir mal

La primera versión del laboratorio tenía una trampa obvia, aunque no la vi al principio. Comparaba la implementación más cómoda de Prisma — usando include para traer relaciones — contra un join manual en JDBC. El resultado era predecible: JDBC medía 1 SQL/request, Prisma idiomatic medía 4 SQL/request en read-by-id, y la latencia lo reflejaba.

Conclusión incorrecta que casi publico: "Prisma es más lento porque emite más queries".

Conclusión correcta: estaba comparando shapes distintos. El include de Prisma hace queries separadas por relación — no es un bug, es el contrato documentado de la API. JDBC hacía un join porque yo lo escribí así. No es fair compararlos sin reconocerlo.

Esa es la fricción que cambió todo el diseño del lab: necesitaba tres niveles dentro de cada stack.

Tres niveles: naive, idiomatic, best-effort

Agregar la columna level al results/comparison.csv fue la decisión más importante del proyecto. Sin ella, cualquier tabla de resultados es una trampa para el lector.

• naive: la implementación más directa posible, sin pensar en performance. En ambos stacks, esto incluye N+1 deliberado — consultas por task dentro de un loop.
• idiomatic: la forma normal y mantenible de escribir el código en cada stack. Prisma con include y _count, JDBC con el join que escribiría cualquier dev Java sin obsesionarse con micro-optimizaciones.
• best-effort: el código más ajustado que acepta el equipo sin convertirse en un hack. Para Prisma, esto significa bajar a $queryRaw cuando el shape es agregacional.

El escenario read-by-id con Prisma idiomatic midió 4 SQL/request por el include. La variante read-by-id-best-effort con $queryRaw bajó a 1 SQL/request — el mismo join que usa JDBC. El plan de PostgreSQL para ese query es limpio:

-- read-by-id-best-effort: mismo SQL en Prisma $queryRaw y en JdbcTemplate
select t.id, t.title, t.status, t.created_at as "createdAt",
       p.id as "projectId", p.name as "projectName",
       o.id as "organizationId", o.name as "organizationName",
       u.id as "assigneeId", u.display_name as "assigneeName"
from tasks t
join projects p on p.id = t.project_id
join organizations o on o.id = p.organization_id
join users u on u.id = t.assignee_id
where t.id = '00000000-0000-4000-0100-000000000001'::uuid
limit 1;
-- Execution Time: 0.242 ms, Buffers: shared hit=9

Cuando Prisma y JDBC emiten el mismo SQL, el plan de PostgreSQL es idéntico. Eso cierra la discusión del runtime: el cuello de botella era el shape, no el cliente.

El N+1 es el villano de siempre, pero el lab lo muestra con números

El escenario n-plus-one-trap existe para hacer explícito algo que cualquier desarrollador sabe en teoría pero subestima en práctica. El nivel naive en ambos stacks hace consultas individuales por task — en un dataset de 50k tasks con concurrencia 16, eso escala de manera brutal.

El salto más importante en el lab no fue entre Prisma y JDBC. Fue entre naive e idiomatic dentro de Prisma. Cuando pasás de N+1 a include/_count, la reducción de SQL/request es inmediata y visible en la latencia. Después, si querés apretarlo más, $queryRaw te da otro salto — pero menor que el primero.

Lo interesante del lado Java es que CountingJdbc — el wrapper sobre JdbcTemplate que está en apps/jdbc-service/src/main/java/com/example/jdbclab/CountingJdbc.java — usa un AtomicLong para contar queries. Eso permite comparar SQL/request de forma objetiva sin depender de logs ni de pg_stat_statements como fuente principal:

// CountingJdbc.java — instrumentación sin magia, fácil de auditar
@Component
public class CountingJdbc {
  private final JdbcTemplate jdbc;
  private final AtomicLong queryCount = new AtomicLong();

  public <T> List<T> query(String sql, RowMapper<T> mapper, Object... args) {
    // cada llamada al wrapper suma 1 al contador
    queryCount.incrementAndGet();
    return jdbc.query(sql, mapper, args);
  }

  public long count() {
    return queryCount.get();
  }
}

Del lado de Prisma, el equivalente está en apps/prisma-client/src/db.ts: se engancha al evento query del cliente para contar. Esa simetría en la instrumentación es lo que hace que los números de SQL/request sean comparables entre stacks.

Cuándo $queryRaw tiene sentido y cuándo es una rendición

Esta es la parte donde muchos posts sobre Prisma no son honestos. $queryRaw existe y es válido, pero usarlo para todo es admitir que no querés usar Prisma — estás usando PostgreSQL con un cliente TypeScript de lujo.

La decisión en el lab fue clara: best-effort con $queryRaw tiene sentido en relation-summary y report-aggregation porque el shape es genuinamente agregacional. Prisma groupBy no expresa limpiamente date_trunc + join por organization, y forzarlo sería peor que escribir SQL.

En cambio, paginated-list no tiene variante best-effort porque Prisma idiomatic ya emite 1 SQL/request con findMany y filtros. Agregar $queryRaw ahí no cambiaría nada relevante — sería complejidad sin beneficio.

La tabla en docs/brief-post.md lo modela bien: la columna level no es una escala de "cuánto esfuerzo pusiste" sino de "cuánto cambia el shape SQL cuando aplicás la variante".

Lo que el lab no puede garantizar

El runner HTTP es propio — no es k6 ni wrk. El hardware es local. Docker Desktop, GC, plan cache e índices pueden mover las latencias absolutas entre corridas. La corrida editorial usó 3 runs, 300 requests por run, warmup de 30, concurrencia 16 y dataset de 50k tasks, pero esos números en otro hardware pueden dar resultados distintos.

La matriz de versiones (docs/java-version-matrix.md) muestra Java 21 vs Java 25: hay diferencias, pero el argumento principal — que N+1 y SQL/request dominan — se mantiene en ambas JVMs. Java 25 mejoró read-by-id un ~20% sobre Java 21 en la corrida local, pero eso no cambia que el problema en relation-summary-naive era el shape, no la JVM.

No publicaría esos números absolutos como verdad universal. Los publico como evidencia de un patrón: cuando cambiás el shape, el delta es órdenes de magnitud mayor que cuando cambiás el runtime.

La postura que me quedé

Prisma no es lento. Prisma con include que emite 4 queries donde podrías emitir 1 es una decisión de ergonomía que tiene un costo observable — y ese costo vale la pena en la mayoría de los endpoints de una API que no está bajo presión extrema. Cuando el shape importa de verdad, $queryRaw existe y funciona bien.

JDBC con JdbcTemplate no es superior por ser SQL directo. Es predecible porque el desarrollador controla el shape desde el primer momento. El riesgo está en el lado opuesto: que nadie revise si esos loops en Java también están haciendo N+1 sin que el ORM sea el chivo expiatorio.

El lab es reproducible. Si tenés Docker, Node 24 LTS y Java 21 o 25, podés correrlo:

# corrida editorial completa — Bash
bash scripts/run-lab.sh --mode editorial --size editorial --runs 3 --requests 300 --warmup 30 --concurrency 16

Y si querés solo verificar que los escenarios corren sin errores antes de comprometer tiempo:

# smoke rápido para validar el setup
bash scripts/run-lab.sh --mode smoke --size small

El código está en github.com/JuanTorchia/prismavsjdbc. Los resultados editoriales están en results/comparison.csv y results/comparison.md.

Lo que me gustaría saber: en el stack que usás ahora mismo, ¿tenés visibilidad real del SQL/request de cada endpoint? ¿O asumís que el ORM lo resuelve solo?