How to tell a query problem from a server problem

"We need a bigger server" usually comes before any real diagnosis

When a product starts to slow down, the infrastructure decision is the easiest one to make and to explain: load grew, resources are short, so add CPU, memory or another instance. Sometimes that is genuinely needed. But without understanding the cause, the result is a bigger bill and the same behaviour three weeks later.

Signals that the problem is deeper than the server

• Not everything is slow — specific scenarios are: reports, lists, checkout, synchronisation, search.
• Response times jump sharply after particular releases, although infrastructure did not change.
• Load peaks lead to locks and timeouts instead of a uniform degradation.
• Background jobs and integrations correlate with the slowdowns users complain about.

What the real cause usually turns out to be

In practice it is heavy queries, unfortunate indexes, wide selects, redundant JOINs, competing transactions, and a schema that no longer matches how the product is actually used. ORM layers suffer separately: they make generic code easy to write, but that code can quietly generate dozens of queries per page. None of this is fixed by adding a node.

How to separate an infrastructure symptom from a data problem

• Look at which business scenarios are slow, not only at which server metrics go up.
• Check whether specific queries and locks correlate with the degradation users report.
• See how background processes, integrations and bulk operations behave at the moment of the peak.

Why mixing the two classes of problem is expensive

Because they have different economics. An infrastructure issue is solved with one set of actions; a query, index and schema issue with another. Treating the second as the first gives the business an unstable system plus a permanent new cost that never delivers the expected speed.

What the investigation should produce

Not a "backend versus DevOps" argument, but a clear picture: where we hit hardware, where the data model, and where the architecture of the whole scenario. Only after that can you start changes that actually reduce degradation instead of postponing it to next month.