On April 30, 2026, MySQL 8.0 reached end of life, which means Oracle's community edition stops receiving security patches. Which clock you're on decides whether you're already exposed, being billed for extended support, or heading for an automatic upgrade you didn't schedule.
Where the major managed providers stand:
- AWS RDS. Standard support ended July 31, 2026. Instances still on 8.0 are auto-enrolled in paid Extended Support at a per-vCPU-hour charge that climbs in year three, running through July 31, 2029. You stay patched, but the bill grows.
- Google Cloud SQL. Paid extended support begins January 1, 2027, with deprecation and a mandatory auto-upgrade to 8.4 by July 1, 2029. You have runway, though an upgrade you don't control is on the calendar.
- Oracle HeatWave. Critical patches continue until April 2027, after which remaining 8.0 instances are automatically upgraded to 8.4 LTS during the next maintenance window.
- Self-managed. No safety net. Once community support ended in April, your 8.0 instances stopped getting security fixes.
If you're self-managed or your provider's window is closing, the exposure is concrete: unpatched database software is a standing target, and EOL versions commonly turn into audit findings under PCI DSS, HIPAA, and SOC 2 well before they turn into a breach.
One catch to plan around is that you can't upgrade straight from 8.0 to 9.7, since the supported path runs through 8.4 first. From there, you can stop at 8.4 for the lower-risk move and stay put, since it's supported into 2032, or continue to 9.7, the current LTS, after validating compatibility.
What to do this week:
- Confirm your version and build:
SELECT VERSION(), @@version_comment;
- Check your provider's support status and billing. Are you already in paid extended support, and when does it end?
- Run MySQL's Upgrade Checker (
util.checkForServerUpgrade()) to surface incompatibilities before you touch anything.
- Validate your drivers, ORMs, and replication topology against 8.4.
- Compare query plans and latency on your important queries between 8.0 and 8.4, since planner behavior can shift.
- Test your rollback procedure, not just the upgrade.
- Set a migration deadline tied to your provider's actual cutoff, not a vague "someday."
The deadline passed months ago, and most instances kept running as if nothing happened, which is what makes it easy to keep putting off. But the meter is running on at least three of the four clocks above, whether as extended-support fees or a scheduled auto-upgrade, which means the upgrade is coming on someone's timeline. The practical move is to make it yours.
Rapidly scaling online storage to serve over 1 billion ChatGPT users
OpenAI's storage platform handles over 70 million requests per second across roughly 40 regions. They constrained it to a NoSQL API because arbitrary SQL made it cheap to write queries that are expensive to run, and one new query on a hot path kept taking the database down.
Introducing WalShadow: Sub-second Postgres replication to ClickHouse from physical WAL
WalShadow reads the physical WAL stream Postgres already ships to replicas, decodes it outside the source, and skips logical replication slots entirely. ClickHouse measured about 200ms commit-to-visible latency against roughly 10 seconds for PeerDB, their own logical-decoding tool. Open source, with a managed version in private preview.
Cache Invalidation for SQL Queries: How to stop writing it yourself: Put a cache in front of your database and the invalidation logic lands in your write path as a short list of rules, and one of them is quietly serving stale data. This benchmark runs six caching strategies against the same workload to show what that mistake costs, and why incremental view maintenance avoids the invalidation problem entirely.
We're getting more social, catch the latest on Bluesky, X, dev.to, and Medium too.
Know a database aficionado who'd appreciate this? Forward it their way.