· ReadyStack
Worked example
Real numbers from this tool, line by line.
$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.
15 seconds — what it actually does
Questions people ask
What does Aurora MySQL 5.7 to 8.0 Upgrade Blocker Lint do?
It reads .sql, .cnf and Terraform files and flags every line that uses a MySQL 5.7 feature removed in MySQL 8.0: query cache settings, PASSWORD(), GRANT that creates users, NO_AUTO_CREATE_USER, tx_isolation, old spatial names, INNODB_SYS_ views and new reserved words like rank. It has 28 rules and prints the 8.0 replacement beside each finding.
Who is this lint for?
DBAs, platform engineers and backend developers who run Aurora MySQL version 2 (MySQL 5.7) on AWS and must move to Aurora MySQL version 3 (MySQL 8.0). It suits teams whose schema migrations, parameter groups and Terraform live in a Git repository and who want the blockers listed before the upgrade window, not during it.
Why not just ask a chatbot or rely on the AWS precheck?
A chatbot does not read your repository line by line and often mixes 8.0 and 8.4 removals. The AWS upgrade precheck runs against a live cluster at upgrade time. This lint runs on the files in your editor, so the 14 findings in a script like the sample dirty.sql are fixed in a pull request before anyone schedules the upgrade.
What is free and what does the full version add?
Free: the open .sql, .cnf or .tf file is checked against all 28 rules in VS Code or the browser page, with every finding and its fix shown. The full version, $29 once with one licence key per person or team seat, scans the whole workspace in one run and exports a dated Markdown upgrade report for the change ticket.
What does staying on Aurora MySQL version 2 cost?
AWS lists RDS Extended Support at $0.200 per vCPU-hour from year 3 in US East (Ohio), and Aurora MySQL version 2 enters year 3 pricing on 1 Dec 2026. One 8 vCPU instance then costs $1,168 a month, or $14,016 a year, on top of the normal instance price, until the cluster is upgraded.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. Aurora MySQL 5.7 to 8.0 Upgrade Blocker Lint checks the file you open against 28 rules from a rule set dated 2026-09-28, and points at the exact line with the fix. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.