Prisma Client is great in giving you the data you ask for, with great DX to create those queries. Under the hood, Prisma sometimes makes seemingly odd choices on how to generate the SQL to get that data though. Often that is based on Prisma supporting multiple databases, which not all support the optimal way to retrieve that data.

In the past, for simplification reasons, Prisma decided to implement the universally available method mostly, and not optimize for specific databases. Now that Prisma is more mature, we decided to change that stance and will optimize queries to the best ability of the individual database.

Prisma also sometimes uses multiple queries when in theory a JOIN could be used to let the database do that work. As Prisma support very extensive nested queries, JOINs often only can be used if the level of nesting is low. But similar to above, we now think that this should not stand in the way of amazing performance for the majority of the queries that are not too complex for JOINs, so we will implement them where possible.

This effort is tracked in a multitude of issues that are grouped under these GitHub labels:

• Label topic: performance/queries
• Label topic: performance
• Label topic: joins