The latest from the MySQL community

Starting with Percona XtraDB Cluster (PXC) 8.0, replication traffic encryption is enabled by default. That said, it’s common to find clusters running without TLS that suddenly need it: a new compliance requirement, an audit finding, a network segment that is no longer considered trusted.

PXC has a variable for exactly that case, pxc-encrypt-cluster-traffic, which handles SSL encryption for inter-node traffic, including State Snapshot Transfer (SST), Incremental State Transfer (IST), and the group communication the nodes use for replication.

The variable is not dynamic, and turning it on normally costs a full cluster restart since the node that encrypts traffic listens on ssl:// while its peers are still on tcp://. If a node joins the cluster with TLS enabled while remaining nodes don’t, the restarting node fails to reach out to the other peers with the following error:

2026-09-02T02:16:02.359992Z 0 [Note] [MY-000000] …

There are a few cryptography tasks that are common to many backends. For example, you should store passwords such that a database leak doesn't expose them, you should sign payloads so the receiving side can verify them, you should keep a column's data unreadable outside the database, and you should mint tokens an attacker cannot guess. MySQL's built-in functions cover part of that ground but fall short for many users. The SHA2() function will hash a password, but nothing salts it for you, so two people who pick the same password end up with the same stored value. MySQL does not have a built-in HMAC function. An HMAC is the keyed hash a receiver uses to tell a real message from a forged one.

When a database doesn't solve a problem natively, the work invariably moves up into application code, where every service reimplements it just a little bit differently. This adds ongoing maintenance complexity.

The …

An engineer leaves your company. You disable their single sign-on account, and their access to the wiki, the cloud console, and the CI system goes with it. Typically, access to database resources doesn't follow such a simple plan. Database user and role maintenance too often happens within the database, oblivious to single sign-on. User accounts carry a password which has to be managed and rotated (and the password is probably already sprawled out across shell history and a shared password manager).

An easier way to manage this is to bring the identity-provider model to the database. This is what the VillageSQL Server vsql-oauth2 extension does. It adds an authentication method that accepts an OAuth2/OpenID Connect token (a JWT) from your identity provider in place of a password. Your identity provider decides who can log in, MySQL privileges decide what they can do …

VillageSQL Server 0.0.6 is now available. This release advances the mainline to MySQL Server 8.4.11 and adds support for MySQL Server 9.7.2 and Percona Server 8.4.10.

Highlights of this release include the following:

• An extension can now log you in, so your identity provider decides who gets into the database.
• Extensions can call the server's own internal component services, which opens up a large part of the MySQL surface area.
• A privilege of its own now covers extension management, so you can grant that and nothing else.
• If you build a custom type incorrectly, you find out when you compile the extension or when you install it, rather than when someone runs a query.

VillageSQL now runs on MySQL Server 9.7 and Percona Server 8.4

VillageSQL Server 0.0.6 adds a mysql-9.7 build that tracks the MySQL Server 9.7.2 tree, and a percona-8.4 build …

The common practice is to size the Galera Cache based on write volume measured during peak load, but often it is more of a guesswork. The writeset cache capacity planning is crucial to shorten the maintenance time and avoid long state transfers while the cluster runs with reduced compute power. Now, if you could understand what’s exactly inside the cache, wouldn’t the planning be more aware as compared to only calculating the best size based on wsrep_received/replicated_bytes variables?

Similarly, while dealing with various incidents occurring in Percona XtraDB Cluster or MariaDB Galera Cluster environments, how many times did you stumble upon the fact that the GCache file (galera.cache) is a black box and you can’t inspect it in a meaningful way? 

In some scenarios, having the opportunity to see what exactly ended up in the cache file(s) could help us understand the write workload impact or what happened …

NOTE: We are back after a summer break! Hope you enjoyed the beach and long summer nights.

As part of building the MySQL Community, we are going to publish a curated overview of MySQL and database news and events that you might have missed over the last period.

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)

More to Explore: What’s New on Planet MySQL
TL;DR - Scott Stroz and team are doing major …

Our first post showed MySQL 9.7 with one change: mark a table ENGINE=DuckDB and its analytical queries run in DuckDB instead of InnoDB. The question we kept getting after that was about replication. Can you keep a normal InnoDB primary for the writes, and run a replica where the big tables are ENGINE=DuckDB? Then the heavy reports run on a column store, and ordinary MySQL replication keeps it current. No export job. No second database to sync by hand.

So we tried it. The first run failed, and it failed in a way that is easy to miss: the replica took every transaction, reported success, and stored nothing. We tracked down why, fixed it, and the whole test suite passes now. This post is what we tested, how we checked it, the bug we found, and where it stands.

It’s still an experiment, not production software. The code and the test harness are on GitHub under GPLv2: …

We ran DuckDB MySQL storage engine at scale factor 500. It is around 500 GB of raw TPC-H, three billion lineitem rows  on an 80-core server with 187 GB of RAM. Three engines on the same box: InnoDB, our MySQL+DuckDB engine, and plain DuckDB as the reference.

Here is what came out. InnoDB finished 18 of the 22 queries and spent more than 28 hours of query time on them. Four never finished. Our engine ran all 22 in about three minutes. It loaded the data 25 times faster than InnoDB, and it used 5 times less disk. On the queries it stays close to plain DuckDB, and on a few it is ahead.

It’s still an experiment, not production software. Code and the benchmark harness are on GitHub under GPLv2: https://github.com/Percona-Lab/ducksdb-mysql-engine.

The machine, and how we ran it

• One server, 80 cores, 187.5 GB RAM.
…

“Through transparent roadmaps, community-driven collaboration, contributor programs, and the MySQL Governance model, we aim to create an environment where innovation can accelerate while preserving the reliability, compatibility, security, and operational excellence that organizations around the world depend on.”

Q1. Oracle has announced a “new era” of MySQL community engagement at MySQL’s 30th anniversary. Can you walk us through what specifically prompted this strategic shift, and what concrete changes can the community expect to see in how Oracle approaches MySQL development and governance?

HVC: Throughout 2025 we celebrated 30 years of MySQL and reflected on the past and present, but more importantly, the future. The MySQL Community team sought feedback from around the globe on how to lead the next generation of MySQL innovation and open source collaboration. We came to Jason …

VillageSQL Server 0.0.5 is now available (and marked as the stable release for installs). This release is focused on the extension lifecycle: upgrading an extension in place, pinning the exact version you install, and seeing what's running. The extension framework also adds variable-length custom types and statement-event hooks. VillageSQL Server 0.0.5 tracks Oracle MySQL 8.4.10 and includes all upstream fixes from that branch.

Upgrading extensions

One of the most critical pieces of managing an extension is being able to upgrade it. ALTER EXTENSION introduces the syntax for upgrade, and with it the safety checks that run before an upgrade is allowed to touch your data.

ALTER EXTENSION my_ext VERSION '2.0.0' AT RESTART;

Asking for the version you already have is a no-op with a note. Asking for a different version triggers a set of pre-checks against the target package: it refuses an …