MySQL 9.7 LTS: What Production Teams Need to Know

MySQL 9.7.0 LTS was released this week. For most teams running MySQL in production, this is the upgrade decision many have deferred since 8.4.

Since the 8.4 LTS release in 2024, MySQL has been shipping quarterly Innovation releases from 9.0 through 9.6, adding new capabilities at a pace most production teams were not willing to track. Those releases were never designed to be standardized on. MySQL 9.7 is the point where two years of innovation closes into a stable, long-term supported branch, with five years of premier support from Oracle. The question is no longer whether to upgrade from 8.0 or 8.4, it is how and when.

A few things in this release that are worth knowing before you plan that upgrade:

• The Hypergraph Optimizer is now in Community Edition. MySQL's more advanced query planner was previously Enterprise-only. It makes a real difference for queries with complex joins and multi-table patterns, where the standard optimizer often settles for a suboptimal plan.
• mysql_native_password was removed in 9.0 and is not present in 9.7. The shared object no longer exposes the symbol the server needs, which means it cannot be loaded even as a plugin. Any service account still using the old authentication plugin will fail to connect after upgrading. Migrating to caching_sha2_password before touching the upgrade is not optional.
• JSON Duality Views now support full DML in Community Edition. The ability to insert, update, and delete through JSON Duality Views was previously gated behind an Enterprise license. It is no longer.
• Replication observability is meaningfully better. Multi-threaded replication metrics, Group Replication health detection, and improved lag visibility are all now available in Community Edition, tools that have been Enterprise-only until now.

For teams upgrading from 8.0, which reached end of life this month, the supported path is 8.0 to 8.4 first, then 8.4 to 9.7. LTS versions cannot be skipped. The transition is considerably less disruptive than the 5.7 to 8.0 upgrade was; there are no major architectural changes, and the primary migration work for most teams will be the authentication plugin change.

For teams running Readyset alongside MySQL, Readyset supported 9.7 on launch day. The same image you deploy today works with 9.7 as an upstream without any additional configuration. This post walks through what that looks like in practice.

🔍 What We're Watching in the Database Ecosystem

Can AI Agents Answer Your Data Questions? A Benchmark for Data Agents

Researchers from UC Berkeley, University of Washington, and Hasura set out to measure something that most AI benchmarks skip: how well do AI agents actually perform when data is fragmented across multiple heterogeneous database systems, with inconsistent references and business logic buried in unstructured text? Their Data Agent Benchmark (DAB) covers 54 real-world queries across 12 datasets, 9 domains, and 4 database systems. The results are a useful reality check for any team evaluating AI-driven data access in production environments.

MySQL 9.7.0 Release Notes

The 9.7.0 release notes. Worth going through carefully if you are planning an upgrade, maintaining tooling that connects to MySQL, or want to understand exactly what changed in this release. Teams upgrading from 8.4 should also review the 9.0 through 9.6 notes for the complete picture.

In Case You Missed It

MySQL Live Wire - MySQL 9.7 with Vinicius Grippa: Readyset engineer Vinicius Grippa joined Scott Stroz on MySQL Live Wire to break down what's new in MySQL 9.7, what the LTS designation means for production teams, and what to watch out for when upgrading.

New on our blog:

Readyset Is Ready for MySQL 9.7 - Three Commands with rdst: Readyset supported MySQL 9.7.0 LTS on launch day. This post walks through three rdst commands to register a 9.7 instance, deploy Readyset via Docker, and benchmark cached vs. upstream query performance.

Why LLMs Write Incorrect SQL (and What That Means for Your Database): Most LLM-generated SQL runs and returns results, which is exactly what makes it dangerous. This post covers the subtle, schema-specific failure modes that don't throw errors and the patterns teams are using to catch them before they reach production.

Replication Internals: Decoding the MySQL Binary Log Part 8: Row Events - WRITE_ROWS, UPDATE_ROWS, and DELETE_ROWS: Marcelo continues the series with the row events, the events that carry the actual data for every INSERT, UPDATE, and DELETE in row-based replication. Part 8 decodes all three event types byte by byte, covering how before-images and after-images are structured, how column bitmaps work, and what changes when binlog_row_image is set to MINIMAL.

Know a database aficionado who'd appreciate this? Forward it their way.