The database first, always
Business applications rarely become slow because PHP cannot keep up. They become slow because query count grows with data volume, or because an index that was unnecessary at ten thousand rows is essential at a million.
Adding application servers in front of a database that is the bottleneck makes the bottleneck worse, not better.
The order of work
- Fix query multiplication — loops issuing one query per row
- Add missing indexes on filtered and joined columns
- Move reporting to a replica or a nightly copy
- Cache what remains genuinely expensive
- Then add capacity, if it is still needed
Watch data volume, not user count
- A query that scans a table gets slower as the table grows
- Reports over all history get slower every month
- Log and audit tables grow indefinitely unless managed
- Search over free text degrades without proper indexing
Applications frequently slow down with no change in usage, purely because the data has grown past what the original queries assumed.
Archive old data
Most business applications keep everything forever because nobody decided otherwise. Moving old records to an archive table or a separate store keeps the working set small and the queries fast.
It also makes backups faster and restores quicker, which matters more than it sounds during an incident.
Then horizontal capacity
| Step | When |
|---|---|
| Bigger server | Simplest, works for a long time |
| Read replica | Reporting and read-heavy load |
| Multiple application servers | Concurrency limits reached |
| Separate queue workers | Background work competing with web |
| Sharding | Rarely, and it is a large step |