Stop Paying Extra: How We Helped an Ad-Tech Company Cut AWS RDS Costs by Upgrading from MySQL 5.7

26 / Aug / 2025 by Karandeep Singh 0 comments

Introduction

If you’re still running MySQL 5.7 on Amazon RDS, it’s time to act. AWS started charging for Extended Support in March 2024. By mid-2025, that charge is no longer theoretical, and paying for it is kind of unacceptable. You’re likely already paying for it, and the cost will double by the end of this year.

Migrating from MySQL 5.7 on Amazon RDS

Migrating from MySQL 5.7 on Amazon RDS

We recently helped a fast-growing ad-tech company migrate all of their MySQL 5.x RDS instances to MySQL 8.x, saving them over $3,000 per month. In this blog, I’ll walk you through what changed, what we did, and how you can avoid these hidden charges too. Let’s get started and explore this.

What Changed in RDS?

MySQL 5.7 reached the end of standard support in October 2023, and AWS began charging for Extended Support in March 2024.

The pricing:

  • $0.10 per vCPU-hour from March 2024 through December 2025.
  • $0.20 per vCPU-hour from January 2026 onwards.

To put that in perspective:
If your RDS instance has 8 vCPUs and runs 24×7, you’re paying around $576/month right now, and that cost will double to $1,152/month starting next year. That’s just one RDS instance.

The Real-World Case: A Global Ad-Tech Company

We at TO THE NEW worked with a global ad-tech company that had more than 20 MySQL 5.7 RDS instances across production, qa, integration, and development environments.

Here’s what we discovered:

  • Unaware: Many teams didn’t know they were still on MySQL 5.7.
  • FinOps Nightmare: Several non-prod DBs were oversized and running 24×7.
  • Rising Cost: If left untouched, extended support charges would’ve crossed $3,000/month.

    AWS RDS Extended Support Cost

    AWS RDS Extended Support Cost

What We Did

  • Identified all RDS instances still running MySQL 5.7.
  • Planned upgrades with minimal downtime.
  • For production mysql upgrades, we used RDS Blue/Green deployments and snapshot testing.
  • For dev/staging and other lower environments, we used the mysql dump-and-restore method, accepting a little downtime.
  • Decommissioned old, unused, and idle databases.
  • Upgraded all environments to MySQL 8.0.

The Results

  • Saved over $3,000/month in AWS charges.
  • Avoided future cost spikes as the per-CPU pricing doubles in January 2026.
  • Improved performance in several use cases thanks to mysql engine-level enhancements.
  • We took this opportunity to migrate non-graviton RDS to graviton, which gave us more savings and better performance.
  • Gained better visibility into RDS usage with consistent tagging and version tracking.

Why MySQL 8.x Was More Than Just a Cost Fix

  • We upgraded to save money, but the performance boost was the surprise win. A few things we noticed right away:
  • Queries using GROUP BY and joins ran significantly faster.
  • The JSON column performance was much improved.
  • New features like CTEs (common table expressions) and window functions made life easier for analysts.
  • Better indexing behavior and performance schema insights.

For many teams, this was the first time they wanted to upgrade a database. That’s rare.

Key Lessons

  • Non-prod environments are often ignored, but AWS still charges for them.
  • Upgrade risks are lower than most teams assume, especially with snapshot-based testing.
  • Extended Support is a silent cost leak — easy to miss until the bill hits.

What You Can Do Right Now

1. Find All MySQL 5.7 Instances.
Run this command to list outdated RDS databases:

aws rds describe-db-instances \
--query "DBInstances[?Engine=='mysql' && starts_with(EngineVersion, '5.7')].[DBInstanceIdentifier, EngineVersion]"

2. Test the Upgrade in Staging or Dev.
Use snapshots or clone the DB, then upgrade manually to validate behavior.

3. Upgrade Production with Care:

  • Use RDS Blue/Green deployments
  • Schedule migration and downtime carefully
  • Communicate early with all stakeholders.

4. Clean Up What You Don’t Need
Identify and terminate idle RDS instances, especially in development environments.

5. Use Scheduled Stopping for Non-Prod Databases
Consider stopping RDS over weekends or off-hours to reduce cost.

Final Thoughts

Database upgrades are not fancy, but they’re often where real savings hide. With a little planning, you can cut unnecessary spending, reduce risk, and modernize your stack in one move. At To The New, we help companies avoid these hidden AWS traps every day — whether it’s RDS, MSK, S3, or NAT Gateway costs.
If you’re still running MySQL 5.7 in 2025, you’re paying extra for being outdated. You don’t need to be.

References (You’ll Want to Click)

FOUND THIS USEFUL? SHARE IT

Leave a Reply

Your email address will not be published. Required fields are marked *