Prisma 5.10 and relationLoadStrategy: a join in the right place

Prisma 5.10, released in February 2024, shipped a long-requested preview feature: relationLoadStrategy. In a single line of code, the Prisma team untied one of the knots that most often hurt us in production.

The recurring problem

When you write a Prisma query with include, Prisma generates multiple queries: one for the main table and one per relation. For small datasets it is fine. For large ones, latency multiplied by N relations becomes visible, especially with a remote database.

// 1 query for posts + 1 for authors
prisma.post.findMany({
  include: { author: true },
});

This is the multiple queries strategy. It is robust because it avoids row duplication on 1-N relations, but it is slow when the database round-trip is high (e.g., Vercel + Neon, AWS Lambda + RDS).

What relationLoadStrategy does

From Prisma 5.10, enabling the relationJoins preview, we can pass relationLoadStrategy: "join" and Prisma generates a single query with a LATERAL JOIN (on Postgres).

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

When we need it

On projects where we measured:

• Admin dashboards with paginated lists + 3-4 relations: -40% latency on remote Postgres.
• Cached public endpoints: marginal difference, the cache absorbs it.
• Mutations: no change, the strategy only applies to findMany/findUnique/findFirst.

When not to use it

For relations with unpredictable cardinality (a parent with 10,000 children) JOIN can blow up the data volume — the multiple queries strategy stays healthier. Rule of thumb: use "join" for 1-1 relations and lists with low limits; keep the default for long lists.

Current limits

• Only PostgreSQL and MySQL (no SQLite, no MongoDB) in the first preview.
• Not yet the default — you must enable the preview feature in schema.prisma.
• Prisma metrics do not yet split the two strategies, so measuring via EXPLAIN ANALYZE still pays off.

For us this is one of those small upgrades that, once deployed, lets the backend breathe without having to ditch the ORM or fall back to raw SQL. The direction is right: give the developer control over the execution plan without forcing them out of the abstraction.