Slow Database? Five Causes to Check Before You Rewrite

When an application starts struggling at peak times — month-end, a big campaign, the morning rush — the first proposals are usually a bigger server or a rewrite. Occasionally one of those is right. Far more often, the cause is one of five ordinary problems, all fixable without starting over.

Measure first. Turn on the database’s slow query log, or use its built-in statistics (PostgreSQL’s pg_stat_statements is a common choice), and rank queries by total time spent. The worst offender is rarely the one people suspect.

1. A missing or wrong index

The most common cause by far. A query that filters or sorts on a column without a suitable index has to scan the entire table. On a thousand rows, nobody notices. On a few million, it’s the whole problem.

The tell: one query dominates the slow log, and its query plan shows a full table scan.

2. N+1 queries

The page loads fifty records, then issues a separate query for each one to fetch related data — fifty-one queries where two would do. It’s invisible in development with ten records and crippling in production with ten thousand.

The tell: hundreds of nearly identical, individually fast queries per page load.

3. Unbounded result sets

A query with no limit that returns every matching row. Fine when the table was small; slow and memory-hungry once it grows.

The tell: a query whose runtime grows steadily over months with no code change.

4. Connection pool exhaustion

Every request waits for a free database connection. The database itself is barely working — the application is queuing to talk to it.

The tell: low database CPU, but high application response times and timeout errors under load.

5. No caching where it obviously belongs

The same expensive query runs thousands of times a minute and returns the same answer every time — a product catalogue, a settings table, a dashboard total.

The tell: identical queries, with identical results, at very high frequency.

Why this order matters

All five are fixable in place, usually in days or weeks, with low risk and an easy way back. A rewrite typically takes far longer than estimated, and while it’s happening you’re maintaining two systems and shipping nothing new.

A rewrite is sometimes genuinely right — when the architecture can’t support something the business now needs. But that conclusion should come from measurement, not replace it.

We walk through a typical case in the site crawls exactly when we’re busiest. Performance work is part of our infrastructure practice.