Prisma 5.10 e relationLoadStrategy: un join nel posto giusto

Prisma 5.10, rilasciato a febbraio 2024, ha portato in preview una feature richiesta da anni: relationLoadStrategy. In una sola riga di codice, il team Prisma ha sciolto uno dei nodi che più ci hanno fatto bestemmiare in produzione.

Il problema di sempre

Quando in Prisma scrivi una query con include, Prisma genera più query: una per la tabella principale e una per ogni relazione. Per dataset piccoli funziona benissimo. Per dataset grandi, la latenza moltiplicata per N relazioni diventa visibile, soprattutto se il database è remoto.

// 1 query per i post + 1 per gli autori
prisma.post.findMany({
  include: { author: true },
});

Il pattern è noto come multiple queries strategy. È robusto perché evita problemi di duplicazione su query con relazioni 1-N, ma è lento quando il round-trip al database è alto (es. Vercel + Neon, AWS Lambda + RDS).

Cosa fa relationLoadStrategy

Da Prisma 5.10, abilitando la preview relationJoins, possiamo passare l'opzione relationLoadStrategy: "join" e Prisma genera una singola query con un LATERAL JOIN (su Postgres).

prisma.post.findMany({
  include: { author: true },
  relationLoadStrategy: "join", // un'unica query
});

Quando ci serve

Sui progetti dove abbiamo misurato:

• Dashboard amministrative con liste paginated + 3-4 relazioni: -40% latenza su Postgres remoto.
• Endpoint pubblici cachati: differenza minima, perché la cache assorbe.
• Mutazioni: nessun cambiamento, la strategy si applica solo a findMany/findUnique/findFirst.

Quando non usarla

Per relazioni con cardinalità imprevedibile (un padre con 10.000 figli) il JOIN può esplodere il volume di dati trasferiti — la multiple queries strategy resta più sana. La nostra regola di pollice: usa "join" per relazioni 1-1 e per liste con limit basso, lascia il default per liste lunghe.

Limiti attuali

• Solo PostgreSQL e MySQL (non SQLite, non MongoDB) nella prima preview.
• Non è ancora il default — bisogna abilitare la preview feature in schema.prisma.
• Le metriche di Prisma non riportano ancora distinte le due strategie, quindi misurare via EXPLAIN ANALYZE resta utile.

Per noi è uno di quei piccoli upgrade che, una volta messi in produzione, fanno respirare il backend senza dover toccare l'ORM o riscrivere query in raw SQL. La direzione è quella giusta: dare al developer il controllo sul piano di esecuzione, senza obbligarlo a uscire dall'astrazione.