The latest from the MySQL community

Henrik IngoMySQL Community Architect In May we hosted the first MySQL Contributor Summit 2026. We arrange such Summits every quarter, and it’s a forum where contributors come together and make proposals, and then discuss them, on what they wish to work on, or see someone else work on, in future MySQL versions.  All of the presentations are now […]

The July 2026 MySQL releases are now available, including: MySQL 26.7.0 is the first generally available Innovation release following MySQL 9.7 LTS and the first MySQL release to use the new calendar-versioning model. MySQL 9.7.2 and MySQL 8.4.11 continue the quarterly maintenance cadence for the current MySQL Long-Term Support release lines. A new calendar-versioning model […]

1. What it is about

This investigation began as a performance comparison for different memory allocators. However, during benchmarking, I discovered unexpected effects deserving a more detailed explanation. I hope you find these findings both interesting and useful.

Imagine you need to set up a MySQL database server. Every detail is planned: the operating system, the CPU architecture, the number of cores, the amount of RAM, the storage capacity and speed. On paper the hardware looks like it can handle the workload. But in reality, things rarely go exactly as planned. So, conducting a thorough stress test is the next thing to do.

2. Realities of stress testing

You configure your MySQL server setting the innodb_buffer_pool_size to 70-80% of your available RAM. This creates a large fast buffer for your data and indexes, reducing the need for slower disk input/output.

After …

The fifth MySQL Public Discussion as part of our Community Engagement plan. The plan includes accelerating innovation in MySQL Community Edition, increasing community contributions and expanding the MySQL ecosystem overall. This session was focused on the contributor experience and the ongoing work to make contributing to MySQL more transparent and accessible. The session covered MySQL […]

Today, I was reminded of a MySQL Best Practice, probably generalizable to all databases : using simple types, not complex types.  Such complex types to avoid include the date and time data types (including TIMESTAMP) and ENUM.  Let's see why.

A little history about this, Baron Schwartz, a MySQL Legend who is not involved in the community anymore, compared using the TIMESTAMP type to

Financial services leaders are operating in a moment where resilience is no longer just a technology issue or a regulatory checkbox. It is increasingly a board-level concern tied to continuity, customer trust, and the ability to keep critical services running through disruption.

You've probably all experienced it; another outage and the database is the root cause.  Why are databases such a frequent cause of problems in most tech stacks? Why can't we seem to solve these problems industry-wide?  Are database engineers and database admins just bad at their jobs?

Over my career as a database reliability engineer, I've come to a conclusion which I don't see repeated often:

All practical implementations have to balance the opposing concerns of correctness vs. performance & availability (this is kind of similar to CAP theorem , but not exactly the same).   Perfect correctness with no data loss across geographic distances would result in a database which is too slow or too costly to be useful for most applications. And these constraints cannot be overcome because it's the physical bounds of reality which imposes …

A real-world troubleshooting guide showing how MySQL metadata query behavior can cause Tungsten Replicator to appear stalled despite healthy cluster status, with root-cause analysis and preventive configuration recommendations.

Overview OpenSSL 3.5 integrates a number of algorithms resistant to attack by future quantum computers, commonly referred as Post-Quantum Cryptography (PQC). These include: Possibility of storing the vast amounts of TLS encrypted traffic now and decrypting it later once the quantum computers become capable enough is considered a real problem, so the governments and standards […]

We recently tested the PostgreSQL backup tool pg_basebackup and were very impressed with its remote backup functionality, which allows for both physical local and physical remote backups.

This led us to wonder whether a physical remote backup is also possible using the “new” MySQL Server Clone feature, which was introduced in MySQL 8.0.17 (July 2019).

The MySQL Clone operation can be used to create both a local and a remote copy of the database. The original idea behind this feature was likely to automatically create nodes in an InnoDB Cluster (similar to Percona XtraDB Cluster SST).

Terminology used in the clone operation:

• Donor (source database)
• Recipient (destination database)

The clone operation is initiated from the recipient. The data can be cloned to the recipient’s own directory or, alternatively, to a different directory.

Preparations