SOFTWARE ARCHITECTURE

EN — 2026

Why a bigger server should not be the first reflex when the database slows down

Performance problems are usually query, index, data model and measurement problems before hardware ones.

← Back to all notes

SOFTWARE ARCHITECTURE

Why a bigger server should not be the first reflex when the database slows down

22 September 20268 min readWYN Studio

Growing a server can bring short relief when a dashboard slows down. But the same query model hits the same wall again as data grows.

Measure first

Which endpoint is slow? How long does it wait in the database? Is it the network, the application, locking, or a wrong index? Optimising without splitting real time into pieces is just guessing.

Common causes

  • Fetching more columns and rows than needed.
  • No suitable index on filtered fields.
  • N+1 queries on list screens.
  • A report query locking live transaction tables.
  • Cache strategy used in the wrong place.

Good performance is visible to the user

Even if a query gets milliseconds faster, the real value is the user not waiting and the system consuming fewer resources. Saying “faster” without connecting the technical metric to the workflow stays incomplete.

Source / further readingWYN — System approachThis article does not copy the original content of the source; it is WYN’s practical interpretation. For current headlines, check the publication date and the source page separately.