Amazon RDS is great, until your database sneezes and the bill doubles. In the cloud, the go-to solution for performance is often “just add more”: more CPU, more memory, more dollars. Before you know it, you’re trapped in an endless loop of scaling up instead of smartening up. This article is your exit strategy: how to stop throwing money at cloud databases and start making them work smarter, not pricier.

The Cloud Dream (and the Gourmet Burger Myth)

Amazon RDS is really expensive, but no one wants to talk about it.

When I speak with clients about why they moved their databases to the Amazon (or Microsoft, or Google) cloud, I often hear the same kind of logic I get from friends who went on a weekend road trip for a “life-changing” gourmet burger.

Over coffee, they brag about driving six hours just to taste the best burger ever. But none will admit that, too often, it ended up being something that could’ve come from a mall food court.

This is what I hear from new clients who left their on-prem databases behind and moved to the cloud.

• "We don’t need a DBA anymore." Sure they do - it’s just now called DevOps.
• "We can write whatever code we want." No, they can’t. Bad SQL still leads to bad performance and bigger cloud bills.
• "We don’t need to index, analyze, vacuum, or do database housekeeping." Oh, they definitely do. Performance usually seems fine at first, but that’s only because there isn’t much data yet.
• "We can finally go big data!" Technically, yes. But big data means big infrastructure: more nodes, more read replicas, more cost.

I’ve seen these patterns repeat again and again—eventually leading to cloud bills far higher than expected.

One of my clients moved a small PostgreSQL database to Amazon RDS. One database, about 20 tables, less than 2 GB of data. By all definitions, a small workload.

Still, they ran into performance issues.

• Round 1: They upgraded the RDS instance from “mini” to “medium.” Problem solved, for a few months.
• Round 2: Performance dropped again. Another upgrade. Another short-term fix.
• Finally: They realized something was wrong.

It turned out the initial performance issue was due to a missing index. The second time, it was auto-vacuum. One of the tables acted like a queue, constantly getting small inserts and deletes. The default auto-vacuum settings weren’t aggressive enough.

• The index was fixed by, well… creating the index.
• The vacuum issue? Adjusted the parameters.

Both issues were solvable. But each time the “quick fix” was to throw more resources and money at the problem. And even after those optimizations, their monthly bill (for a multi-zone setup with two read replicas) was shockingly high. I can’t say how much, but let’s just call it “what-the-heck” expensive.

Let me be clear: this isn’t a rant against Amazon. Their service is excellent, and their pricing is in line with other major cloud providers.

I even use Amazon RDS myself - for testing, learning and proof-of-concept builds. But that doesn’t change the fact:

Amazon RDS is expensive.

If you're thinking about moving your database to the cloud or already have, just remember: scaling isn't a substitute for tuning. And cloud convenience shouldn’t mean surrendering your budget to the upgrade loop.

P.S. If you’re trying to guess who the client in the story is by checking my LinkedIn profile… don’t bother. They’re not there.

‍