The latest from the MySQL community

This post collects the main things Marco Tusa covered in his keynote at Percona Live 2026 in Amsterdam: where Percona stands on MySQL, which features landed in the server, and what holds the MySQL community together.

Watch it here: “I Was Going to Show You a Roadmap”, about 18 minutes.

Start with the community, because the rest of it follows from there. In 2011, after the Sun and Oracle acquisitions, O’Reilly stopped the MySQL Conference, and Percona kept a conference going when nobody knew what came next. The community scattered again more recently, and Peter Zaitsev and others regrouped it in the OurSQL Foundation. MySQL, MariaDB, and Percona ship competing solutions. The people running and building them are one community, with one shared interest: this environment stays usable and open. …

The MySQL 26.10.0 Early Access Release is now available, giving developers and database teams an early opportunity to preview, evaluate, and provide feedback on the next evolution of MySQL. Early Access releases are where curiosity becomes contribution. Whether you’re testing an application stack, validating upgrade plans, or simply eager to see what’s coming, this is […]

AI database governance can get overlooked when teams rush to connect AI tools to production data. IBM’s 2025 research found that 97% of organizations that reported a breach involving an AI model or application lacked proper AI access controls. The risk is easy to see. Give an AI agent too much access and it can […]

The post Database governance in the AI era: Framework, risks and best practices appeared first on Devart Blog.

Create a MySQL database from Node.js with one query. The trick is connecting without naming a database first, running CREATE DATABASE IF NOT EXISTS, then verifying the schema exists. Here is how to do it with mysql2 and handle the failures you will hit in production. The SQL you need IF NOT EXISTS is the […]

The Model Context Protocol (MCP) has become a standard way for AI agents to discover the tools an application, database, or service offers. Claude Code, Codex, Cursor, Antigravity, et al. can connect to an MCP server, ask it what tools are available, and call these tools instead of figuring out what they can or can't do on the fly or piecing together API calls. Setting up an MCP server for a database usually means running a separate process that holds a database credential and turns tool calls into queries. Then you have another process to deploy, another place a credential lives, and a set of guardrails that sit outside the database.

The vsql-mcp extension from VillageSQL takes a different approach. It puts the MCP server inside the database. Install it, set a handful of global variables, and your MySQL server itself serves MCP over Streamable HTTP from a background …

The MySQL Community conversation continues this fall with two opportunities to connect, share feedback, and help shape the future of MySQL.  Following the recent Contributor Summits and Public Discussions, we are continuing to expand practical ways for users, developers, DBAs, partners, and contributors to participate in technical discussions, share ideas, and collaborate more openly across the MySQL […]

EmergencyReparentShard operations are being hardened in upcoming release v25. In this blog, we cover how ERS works and the upcoming changes that make recovery safer, faster and less brittle What is EmergencyReparentShard? # EmergencyReparentShard (ERS) is the Vitess failover process used when a shard's current primary is dead or unreachable. While PlannedReparentShard gets a clean handoff from a healthy primary, ERS has to pick a replacement using only surviving tablets. It compares their transaction histories, promotes an eligible replacement, updates the topology and points the other tablets at the new primary.

Simplify MySQL management with Nutanix Database Service (NDB). Automate database provisioning, instant cloning, fast recovery, and TDE key management.

Before MySQL 8.0, DDL was not crash-safe. There were three main problems:

1. The metadata in the server layer and the metadata/data in InnoDB could become inconsistent.

   The server-layer metadata was stored in files — for example, table definitions were kept in .frm files — while InnoDB kept its own copy of the metadata in its tables. A crash could leave the server-layer metadata inconsistent with InnoDB’s metadata or even with the table data. For example, the server layer still had the table’s .frm file and believed the table existed, but InnoDB’s .ibd data file was gone, so InnoDB believed the table did not exist.

2. InnoDB’s metadata and data could become inconsistent.

3. The binlog and the data could become inconsistent.

   For example, after a crash and …

Welcome back. This issue covers five weeks rather than the usual one — the gap since the August issue took in Percona Live Amsterdam, the launch of the OurSQL Foundation, and the run-up to the MySQL Galera Cluster end of life on 30 September.

If you want to get these updates, just subscribe to the blog.

Enjoy!

MySQL News

Note: Aggregated MySQL news can be found at Planet for MySQL Community and Planet MySQL (Oracle curated)

DISTANCE() and VECTOR_DISTANCE(): Vector Similarity in Percona Server for MySQL …