Cloud, Data & AI
Database Performance: Why Your Site Slows Down as It Grows
Sites rarely get slower because of traffic. They get slower because queries that were fine with a thousand rows are not fine with a million.
A pattern we see constantly: a site launches fast, performs well for a year, then becomes sluggish. Traffic has not changed much. What has changed is the amount of data, and queries that were instant against a small table are now scanning millions of rows.
The Usual Culprits
Missing Indexes
This is by far the most common cause. Without an index, the database examines every row to find matches. At a thousand rows nobody notices. At a million, the same query takes seconds and holds a connection open while it runs.
The fix is usually small: identify the slow queries, look at what they filter and sort on, and add indexes to match. It is often the single highest-return change available, and it is where we start in database development and optimisation.
The N+1 Query Problem
A page fetches fifty products, then runs one extra query per product to get its category. That is fifty-one queries where two would do. ORMs make this easy to do accidentally because the code looks perfectly reasonable.
It hides well in development, where the data is small and the database is local. In production, with real data and network latency, it dominates page load time.
Queries With No Limit
"Fetch all orders" is harmless in year one and dangerous in year three. Any query that can return an unbounded number of rows will eventually return too many. Pagination is not only a UI concern.
Doing Work on Every Request
Expensive aggregations — totals, counts, reports, dashboards — recalculated on every page view are pure waste when the underlying data changes rarely. Caching results, or maintaining summary tables, removes that work entirely.
How to Find the Real Problem
Do not guess. Enable the slow query log, then look at what actually appears — it is frequently not the query people suspect. Use EXPLAIN to see whether a query uses an index or scans the table; a query reporting a full scan on a large table is your answer.
Measure before and after. "It feels faster" is not a result. We diagnosed a rental marketplace's database performance this way, and the fix turned out to be a handful of indexes and one restructured search query rather than the bigger server that had been proposed.
Scaling Up Is the Expensive Answer
Moving to a larger database server does work, and it is usually the costliest way to buy time. A badly indexed query on a bigger machine is still a badly indexed query — you have simply paid to run it faster. Fix the queries first, then size the infrastructure for what remains. When you genuinely do need more capacity, that is a cloud and DevOps exercise, including read replicas and connection pooling.
When it genuinely is the server, a tuned one is often worth more than any caching plugin — that is the substance of our hosting and server management work.
Where Caching Belongs
Caching is powerful and frequently misapplied as a way to hide slow queries. Used well it removes repeated work: an in-memory cache such as Redis for hot data, HTTP caching for pages that rarely change, a CDN for static assets. Used badly it adds stale data and a new class of bug. Cache deliberately, with clear invalidation rules.
It Is Rarely Only the Database
Slow pages usually have several contributing causes: unoptimised images, render-blocking scripts, third-party tags and slow queries together. A proper website speed optimisation engagement measures all of them rather than assuming. Our guide to improving Core Web Vitals covers the front-end half in detail.
If the application code itself is the bottleneck, that is a different fix again — see troubleshooting and bug fixes.
If your site has got slower as it has grown, tell us what changed and when. A short diagnostic usually identifies the cause quickly, and the fix is often far smaller than people expect.
Frequently Asked Questions
Why does a website get slower over time even when traffic stays the same?
Usually because the amount of data has grown. Queries that were instant against small tables start scanning millions of rows once data accumulates, especially when tables lack indexes or queries return unlimited results. The site has not changed, but the work each page asks the database to do has multiplied.
How do I find which database queries are slowing my site down?
Enable the slow query log and review what actually appears there, because the culprit is often not the query people suspect. Then run EXPLAIN on the worst queries to see whether they use an index or scan the whole table. Measure page and query times before and after each fix.
What is the N+1 query problem?
The N+1 problem happens when code loads a list and then runs one extra query for every item in it, for example fifty products followed by fifty separate category lookups. It hides in development with small local data, but in production it can dominate page load time. Eager loading or a single joined query fixes it.
Should I upgrade my database server or optimise queries first?
Optimise queries first. A larger server does buy time, but it is usually the most expensive option, and a badly indexed query is still badly indexed on bigger hardware. Adding the right indexes and fixing a few heavy queries often solves the problem outright, after which you can size infrastructure for what remains.
Can caching fix a slow database?
Caching helps when it removes genuinely repeated work, such as storing frequently read data in Redis or caching pages that rarely change. Used to hide slow queries it introduces stale data and new bugs. Fix the underlying queries first, then cache deliberately with clear rules for when cached data is refreshed.
