What Happens as Usage and Data Grow

Data volume, not user count

Django applications rarely slow down because of concurrent users. They slow down because a query that scanned ten thousand rows now scans a million.

Applications frequently get slower with no change in usage at all, purely because the data grew past what the original queries assumed.

The order of work

1. Fix query multiplication — lazy loading in loops
2. Add missing indexes on filtered and joined columns
3. Move reporting to a replica or aggregate tables
4. Cache what remains genuinely expensive
5. Then add capacity, if still needed

Archive what is no longer in use

Most business applications keep everything indefinitely because nobody decided otherwise. Moving old records out keeps the working set small and every query fast.

It also makes backups faster and restores quicker, which matters more than it sounds during an incident.

Then horizontal capacity

Watch the connection pool

Application server processes multiplied by connection pool size must stay within the database's connection limit. Exceeding it under load produces confusing intermittent failures.

It is a simple calculation and it is frequently the cause of problems that look like something more complicated.

Frequently asked questions