We Cut Aurora PostgreSQL Cost by 78%. Not by Tuning Queries — But by Changing the Pricing Model.

We Cut Aurora PostgreSQL Cost by 78%. Not by Tuning Queries — But by Changing the Pricing Model.

There's a dangerous kind of problem in engineering — the kind where nothing looks broken.

Systems are running.
Queries are performing.
Dashboards are green.

And yet… the bill keeps climbing.

That's where this started.

The Problem Nobody Could See

We were running an OLTP workload on Amazon Aurora PostgreSQL.

Daily cost averaged $248.23 per day.

Nothing was failing.
Nothing was slow enough to raise alarms.

But the cost kept creeping up — and more importantly, no one could clearly explain why.

Because when systems are stable, most teams don't ask:

"Why does this cost what it costs?"

They ask:

"Is it working?"

The Wrong Assumption

Like most teams, we approached this as a performance problem.

We tuned:

• Queries
• Indexes
• Execution plans
• PostgreSQL statistics

We assumed cost would follow performance.

But it didn't.

Because cost in Aurora PostgreSQL isn't just about performance — it's about how your workload consumes billable resources.

What We Found

This was a high-throughput OLTP workload with a large amount of data concentrated in a single table.

• One query appeared to drive ~90% of observed I/O

So we removed it.

And… the cost barely moved.

The Turning Point

We stopped looking at queries and started looking at the bill.

What we found:

~75% of our Aurora PostgreSQL cost was driven by I/O.

Even after removing the biggest offender, I/O still dominated.

Because what we initially saw was influenced by buffer cache, not actual disk reads.

What AWS Says

Aurora I/O-Optimized can provide up to 40% cost savings when I/O exceeds 25% of total database spend.

There are zero charges for read and write I/O operations in I/O-Optimized.

https://aws.amazon.com/about-aws/whats-new/2023/05/amazon-aurora-i-o-optimized/

The Real Problem

AWS says:

• 25% I/O → consider switching

We were at:

• ~75% I/O

At that point:

You're not tuning.
You're fighting the pricing model.

The Change That Actually Mattered

We switched from Aurora PostgreSQL Standard to Aurora PostgreSQL I/O-Optimized.

Why That Worked

Aurora Standard:

• Pay per I/O request

Aurora I/O-Optimized:

• No per-request I/O charges
• Pay for compute + storage only

We weren't on the wrong instance size.

We were on the wrong cost model.

What We Didn't Do

We didn't scale our way out.

Instead:

• Reduced reader nodes
• Removed autoscaling
• Scaled only for performance

Because:

You can't out-scale a bad pricing model.

The Result

• $248.23/day → $54.00/day
• 78% cost reduction
• ~$5,800/month saved
• ~$70,000/year saved

A Practical Rule of Thumb

• 25% I/O → evaluate I/O-Optimized
• ~75% → you're already late

The Real Lesson

A system can be fast, stable… and still expensive.

Because:

Cost is tied to I/O behavior.
Pricing is tied to configuration.

Final Thought

If your Aurora PostgreSQL costs keep climbing and nothing looks wrong…

It's probably not performance.

It's a pricing model problem.