Your app is fast because there's almost no data in the database

A scenario is becoming more and more common. With an app written with AI assistance, every click feels fast during testing. On launch day, the list page spins so long that users just close it.

The problem usually isn't the server, and it isn't the database configuration. It's in the code.

First, look at a screenshot.

This TypeScript first fetches all orders, then loops through each one with a for loop and performs a separate query for the corresponding user inside the loop body. The logic is clear, and it reads smoothly. With 20 rows of test data, response time is almost zero.

This pattern has a name: the N+1 query. One query gets the list, and N queries fill in the related data. Twenty rows means 21 database round trips, which is imperceptible. Ten thousand rows means 10,001 round trips. Even if each round trip takes only 1 millisecond, that's 10 seconds. In the real world, there is also network latency, connection pool queuing, and missing indexes, so the actual numbers will only look worse.

One developer summed it up very bluntly: your app is fast because your database is almost empty. Speed on test data isn't speed; it's a bill that arrives only when the first real user shows up.

AI-generated code is especially prone to this trap. Ask Claude Opus 5.5 to write a list endpoint with related data, and it will often give you a loop that queries the database inside the loop. The reason isn't complicated: handling items one by one fits human intuition. When the model generates code, it thinks line by line, so what it writes is one query per line. During testing there's little data, so no one notices. Once the data volume grows, the app goes down on launch day, and N+1 is high on the list of causes.

There's a prompt idea worth saving. Let the model find the queries inside loops itself:

Find every place this code runs a query inside a loop, or fires one per item while rendering a list, the N+1 pattern. For each, show the file and how many queries it fires for 100 items, then rewrite the worst one into a single query. Show me the diff first.

Translated, it means: find every place where this code fires a query inside a loop, or fires one per item while rendering a list—the N+1 pattern. For each one, note the file and how many queries it will fire for 100 items, then rewrite the worst one into a single query, and show me the diff first.

The key is the last sentence. Look at the diff before making changes; otherwise the model may go ahead and change a bunch of other things while it's at it.

This prompt won't solve every performance problem, but it can surface one of the most hidden, latest-exploding classes of problems early. When the database is empty, all code is fast. The real question is: when will you find out that it isn't?