The fastest way to make a slow application faster is to give it a bigger server. It's also, in our experience, the most expensive way to solve a problem that usually isn't a hardware problem at all.
We've seen this pattern on more than one client's infrastructure: an application gets slower as data volume grows, and the response — reasonable in the moment, wrong as a long-term strategy — is to bump the RDS instance size, then bump it again six months later, then again. Nobody goes back and asks why the queries got slower in the first place, because the bigger instance made the symptom go away.
Profile before you scale
On an equipment marketplace client with 30,000+ pieces of equipment and 200,000+ related parts, this is exactly what had happened — years of incremental instance upsizing to compensate for query patterns that hadn't kept pace with data growth. We went in and profiled the actual slow queries instead of the server metrics. Missing indexes on foreign keys used in filtering, N+1 queries loading relationships one row at a time, and a couple of admin pages doing full table scans on tables that had grown from thousands to hundreds of thousands of rows. Fixing those meant the same workload that used to require an oversized instance now runs comfortably on something a fraction of the size and cost. The infrastructure spend didn't just go down — it went down because the thing it was compensating for got fixed.
Where the real savings usually are
Query and index work is the biggest lever, and it's the one people skip because it requires actually reading slow query logs instead of clicking "modify instance" in the console. After that:
Reserved instances or Savings Plans for anything running 24/7 and predictable — there's no reason to pay on-demand rates for a database that's been running the same workload for two years.
Autoscaling for anything with real traffic variance, instead of provisioning a static fleet sized for peak load that sits mostly idle the rest of the time.
Offloading static assets and media to S3 with CloudFront in front of it, rather than serving them from the application servers — this alone often reduces both bandwidth cost and app server load enough to downsize the compute layer.
Read replicas for read-heavy workloads instead of continuing to scale up a single primary instance that's handling both reads and writes.
The result that actually matters
One of our ecommerce clients moved off a platform-hosted setup entirely onto a right-sized, self-managed AWS footprint and took their monthly infrastructure cost from around $2,400 to $150 — not by finding a cheaper hosting provider, but by owning the stack and sizing it to the actual workload instead of a platform's default tier. That's an extreme case because it included a full platform migration, but the underlying principle is the same one that applies to a much smaller, targeted cost review: infrastructure cost is usually a symptom of something upstream — an unoptimized query, an oversized default, an asset that shouldn't be hitting the app server — and fixing the upstream cause is nearly always cheaper than paying to compensate for it indefinitely.
When bigger instances are actually the right call
Sometimes the workload genuinely needs the horsepower — real-time analytics over large datasets, video processing, high-concurrency workloads with genuinely high query volume per second. The point isn't "never scale up." It's "scale up after you've confirmed the current instance size is actually the bottleneck," not before you've looked.