Aurora MySQL 8.0 Upgrade — check mysql files before upgrading

$14,016 a year: that is what one 8 vCPU Aurora MySQL version 2 instance costs in AWS Extended Support from 1 Dec 2026, if you are a DBA or platform engineer in US East (Ohio) whose MySQL 5.7 cluster never made it to 8.0.

The dates come from AWS's own Aurora MySQL release calendar. Aurora MySQL version 2, the MySQL 5.7 line, left standard support on 31 Oct 2024. RDS Extended Support year 1 pricing started on 1 Dec 2024. Year 3 pricing starts on 1 Dec 2026, and Extended Support ends for good on 30 Jun 2029. The Aurora pricing page gives the rate for US East (Ohio): $0.100 per vCPU-hour in years 1 and 2, $0.200 per vCPU-hour from year 3. Multiply $0.200 by 8 vCPU by 8,760 hours and you get $14,016 a year for a single instance, or $1,168 a month. In years 1 and 2 the same instance cost $7,008 a year. Add a reader and the bill doubles again.

The way out is the upgrade to Aurora MySQL version 3, which is MySQL 8.0 and has standard support until 30 Apr 2028. The reason many teams have not done it is not the button in the console. It is the pile of old SQL, my.cnf settings and Terraform that quietly depends on things MySQL 8.0 removed.

MySQL's reference manual keeps a list called "Features Removed in MySQL 8.0". It is long. The query cache is gone, so query_cache_type, query_cache_size, SQL_CACHE and FLUSH QUERY CACHE all fail. PASSWORD() is gone, so the old SET PASSWORD = PASSWORD('x') rotation script fails. GRANT can no longer create a user, and NO_AUTO_CREATE_USER in sql_mode stops the server from starting when it sits in an options file. tx_isolation became transaction_isolation. GROUP BY col DESC is a syntax error. EXPLAIN EXTENDED, ENCRYPT(), GeomFromText() and the INNODB_SYS_TABLES view are gone or renamed. And 8.0 added reserved words: a column called rank or groups, unquoted, no longer parses.

I wrote those rules down as a linter. Aurora MySQL 5.7 to 8.0 Upgrade Blocker Lint has 28 rules, one per removal or group of removals, each with the 8.0 replacement. It reads .sql, .cnf and .tf files. It skips comments, except MySQL's executable /*! */ comments. In Terraform it flags engine_version = "5.7.mysql_aurora.2.x" and the aurora-mysql5.7 parameter group family.

To test it I took a 23-line legacy script of the kind that sits in every old repository: a query cache setting, tx_isolation, NO_AUTO_CREATE_USER, a GRANT that creates a user, a PASSWORD() rotation, a leaderboard table with rank and groups columns, a partitioned MyISAM table, a GROUP BY DESC report, ENCRYPT(), AsText(GeomFromText()), EXPLAIN EXTENDED and a query on INNODB_SYS_TABLES. The lint returns 14 findings on 13 lines. The rewritten version, with CREATE USER, backticked names, ORDER BY and ST_ functions, returns 0.

Why not ask a chatbot? A chatbot does not read your repository line by line, and it often mixes the 8.0 removals with the 8.4 ones, which are a different list. The AWS upgrade precheck is useful, but it runs against a live cluster when you are already in the upgrade window. A lint in the editor moves the work into an ordinary pull request.

The free part is complete on its own: open a .sql, .cnf or .tf file in VS Code, or paste it into the web page, and you get every finding from all 28 rules with its fix. The full version adds one thing: a single command that scans the whole workspace, every migration, parameter group and Terraform module, and writes a dated Markdown upgrade report for the change ticket.

If you still have a 5.7.mysql_aurora.2 string anywhere in your Terraform, start with that file.