Why does an app make 100 requests instead of one? (the N+1 problem)

A slow page often hides a quiet flaw: instead of asking for everything it needs in one go, the app asks the database the same question once per row. This is the N+1 problem: one query for the list, then N more queries for the details of each of its N items.

The analogy: grocery shopping

You have twenty items to buy. Method one: you go to the shop, pick up one item, go home, then head out again for the next. Method two: one trip, one basket. The contents are the same, but the first method takes twenty times longer.

An app with an N+1 problem uses method one. Each round trip to the database is short, but it has a cost: a wait, a bit of work for the database, and it all adds up.

An example

Take a shop with 200 products (an illustrative example). The home page shows each product with the name of its category.

1. The app asks for the list of products: 1 query.
2. Then, for each product, it asks for its category: 200 queries.

That is 201 queries to display one page, when one or two would have done. With 10 products, nobody notices. With 200, the page slows down. The flaw grows with your data, which is why an app can feel fast at launch and sluggish a few months later.

Why it is so common

The code that causes it looks perfectly clean: a loop over the products, and inside the loop, "give me its category". Many database tools hide the query behind a simple line of code, so you never see it. Code generated by AI can produce it too, because it works fine on a tiny test set.

How to spot it

• A page that slows down as the list gets longer.
• Monitoring tools or logs showing the same query repeated dozens of times for a single page.
• A long response time even though the server is barely loaded.

How to fix it

You ask for everything at once:

• load the related items together with the list (many tools offer "eager loading");
• or ask for all the categories in one go for all the products, then attach them in memory;
• or merge the two requests into one with a join.

When the right query is itself slow, a database index helps the database find the data quickly, and a cache avoids redoing it on every visit. For the wider picture of other causes, see why an app is slow.

Key takeaway

The N+1 problem turns one page into a burst of small queries: the fix is to ask for everything at once. If a page slows down as the data grows, it is the first suspect.

And for your product?

This kind of flaw is not visible on screen. It shows up in the code and in the queries that are actually sent. A code audit of your app can find the affected pages and tell which ones are worth fixing first. If you like, we can talk about it in a 30-minute call.