An N+1 query happens when code fetches a collection and then makes another database query for each item. To prevent an AI coding agent from creating that pattern, give it a project rule: inspect where queries run, prefer a batched or nested Prisma read when related data is needed for a collection, and verify the resulting queries. That instruction can steer Cursor or Claude Code, but it cannot guarantee correct or faster code. The right fix depends on the response shape, database provider, and installed Prisma version.
Why is Prisma running so many queries?
Consider code that fetches users and then fetches each user’s posts separately:
As an Amazon Associate I earn from qualifying purchases.
const users = await prisma.user.findMany();
for (const user of users) {
const posts = await prisma.post.findMany({
where: { authorId: user.id },
});
}The first call retrieves the users; the loop then issues one posts query for every user. As the result set grows, so does the query count. This pattern can occur in ordinary application loops as well as GraphQL resolvers. Prisma’s query optimization guide defines it this way: “The n+1 problem occurs when looping through query results and performing one additional query per result.”
Free tools Windows power users keep installed
One-click scans. No signup required.
How do I fix N+1 queries in Prisma?
Choose a query shape that matches the data the caller needs. Prisma documents nested reads, grouped lookups, qualifying automatic batching, and relation-loading strategies; they are not interchangeable in every situation.
Use a nested read for parent-and-child results
If the response needs users with their posts, request the related records in the parent query with include:
const users = await prisma.user.findMany({
include: { posts: true },
});Prisma’s documented example retrieves parent and related data using two SQL queries rather than making a separate follow-up query for each parent. Select only the fields the response needs when shaping the query.
Use one grouped lookup when you need a separate collection
If the code needs the posts as a separate collection, collect the parent IDs and use one in filter, then associate the returned records in application code:
const users = await prisma.user.findMany({
select: { id: true },
});
const posts = await prisma.post.findMany({
where: { authorId: { in: users.map((user) => user.id) } },
});This replaces the per-user follow-up calls with a grouped query. The application may still need to group posts by authorId to construct the final response.
Consider a relation load strategy when the project supports it
Prisma documents relationLoadStrategy: "join" as a database-side relation-loading strategy, while "query" runs separate queries and joins the results in the application. Availability, provider support, and preview configuration depend on the Prisma version. Check the project’s installed-version documentation and database provider before asking an agent to use this option; the relation queries documentation and Client reference describe the version-sensitive details.
Do not assume every Prisma call batches automatically
Prisma documents automatic batching for qualifying findUnique() calls made in the same tick, subject to conditions on the filters. That is useful in some GraphQL resolver patterns, but it does not mean arbitrary findMany() calls—or all Prisma queries—are automatically combined. Check the documented conditions for the installed version before relying on batching.
What should a Cursor rule or Claude Code skill tell the agent?
Write the instruction around observable query behavior and the shape of the requested result. For example, a project rule could say:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
When changing Prisma code, inspect whether a query runs inside a loop or resolver and could issue one follow-up query per returned record. If related data is needed for a collection, prefer an appropriate nested read, a grouped lookup using an `in` filter, or a supported relation-loading strategy. Preserve the requested result shape and select only needed fields. Check the project's Prisma version and database provider before using version-sensitive features. Do not claim a performance improvement without evidence; inspect or measure the generated query behavior.This is an instruction aid, not a correctness guarantee. Prisma publishes Cursor guidance that includes project-rule advice, and documents CLI-based synchronization of skills shipped in Prisma packages for agent harnesses including Claude Code and Cursor. Those documents support using rules and skills, but they do not establish the exact current installation path for a particular Claude Code skill advertised in a title. Check the skill’s current package instructions and your project setup rather than assuming a path or command.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How can I confirm the change actually helps?
Query count is a useful way to spot a likely N+1 pattern, but fewer queries alone do not prove lower latency. Data volume, the database workload, and where relation work runs all matter. Confirm the generated calls and compare behavior under a representative workload before making a speed claim.
- Prisma query optimization describes client-level query events for inspecting generated queries and execution times.
- Prisma Query Insights explains how a high query count for one request can indicate N+1 and how annotations can connect Prisma operations to SQL.
Use these diagnostics to understand the actual query behavior and assess a change; a straightforward nested or grouped read does not need to wait for a formal performance investigation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
