Half the industry is sitting on MySQL 5.7 right now, unsupported since last autumn, and calling it stability.
MySQL 8.4 came out today, and the important word in the announcement is not a feature. It is LTS. First long-term release of the new model: innovation releases every quarter for the brave, an LTS every couple of years for production, bugfixes only after that.
People underestimate how much pain the old model caused. 8.0 was a rolling target. A “minor” 8.0.x could change optimizer behavior or deprecate something you used. Staying current meant re-testing, staying behind meant missing security fixes.
So the upgrade argument for 8.4 is the support horizon. You are buying years of predictable patches. For a database that is the correct thing to buy.
The path from 5.7 is two hops, 5.7 to 8.0 to 8.4, no shortcuts. From my notes, what actually bites.
Deprecated features you forgot you use. mysql_native_password is disabled by default in 8.4, and there is always one ancient client that needs it. Run the upgrade checker, then grep your connection configs anyway.
Charset and collation. The 5.7 to 8.0 hop changes defaults around utf8mb4, and mixed collations surface as broken joins and duplicate keys where “the same” strings stop being the same.
Query plans. The optimizer is not your old optimizer. A handful of queries will get slower and no checklist predicts which.
Which is why the real method is rehearsal. Restore a production dump on the new version, replay traffic on a read replica, compare plans for your top queries. Do it twice. The upgrade itself should be the boring part.
One of the 5.7 servers in that half is mine.