Planet MySQL HA Blog
The Planet MySQL HA Blog aggregates content from sources that cover topics related to high availability (HA) for MySQL databases.
TDE performance in PostgreSQL
What’s the impact of TDE on performance? People usually quickly throw together a few graphs with basic measurements and treat that as a complete answer, but the question is a bit more complex than that. In this blog post, I’ll try to explain it in a bit more detail: why showcasing a single graph isn’t good for anything other than marketing.
Introducing Mountaineers: A Way to Say Thank You
You filed a bug report at 11pm because you’d already done the work to isolate it. You answered a forum question that had been sitting unanswered for three days. You wrote a PR. You spent an hour on a call telling us what’s broken about a tool you use every day. None of that is small, and none of it should go unnoticed.
Missed the May 2026 MySQL Contributor Summit? Watch Every Session On Demand
The inaugural MySQL Contributor Summit, held in May 2026, brought together Oracle engineers, customers, partners, and members of the open source community for a full day of technical collaboration focused on the future of MySQL. The Summit featured more than 20 sessions covering topics including AI integration, performance, observability, replication, developer experience, extensibility, and community […]
Dynamic Data Masking (DDM) with MySQL Enterprise Edition 9.7: Reduce your sensitive data exposure.
With the new LTS (Long Term Support) release of MySQL 9.7.0 https://dev.mysql.com/doc/relnotes/mysql/9.7/en/ , Dynamic Data Masking (DDM) is one of the new features introduced as part of Enterprise Edition. The recent blog by Mike Frank, MySQL Product Management Director, details why DDM is important in every industry where PII (Personal Identifiable Information) data is stored […]
MySQL 9.x: Moving Away From SHA1 and MD5
TL;DR If you use MD5(), SHA1(), or SHA() in MySQL today, start planning the move to SHA2(). Beginning with MySQL 9.6, MD5(), SHA1(), and SHA() are no longer native built-in SQL functions in the server binary. They are available through the Legacy Hashing Component: That component should be treated as a stopgap solution. It gives […]
pg_tde: our fork is temporary, our commitment to open TDE is not
Recently we noticed a LinkedIn post promoting open_pg_tde, a fork of our pg_tde, claiming to be more open. I looked at the repository, and have to disagree with their claim. In this blog post, I’ll explain why.
Cross-site Disaster Recovery with Percona Operator for MySQL
A MySQL InnoDB Cluster provides high availability for a single database cluster using Group Replication. This works well for node failures inside the cluster, but disaster recovery usually requires another cluster in a separate location: another Kubernetes cluster, region, data center, or cloud.
MySQL Community Server 26.7 Early Access Release
MySQL 26.7 is the initial MySQL Innovation release following the MySQL 9.7 LTS release and uses the new yy.mmCalVer versioning model for quarterly Innovation releases. This Early Access release provides a preview of selected functionality planned for the MySQL Community Server package and gives users an opportunity to evaluate upcoming changes before general availability. Download MySQL […]
MySQL & MySQL HeatWave Report – June 2026
Keeping up with the MySQL ecosystem is becoming increasingly challenging. Every release introduces new features, performance improvements, security enhancements, and cloud capabilities. While the official documentation is comprehensive, it is not always easy to quickly identify what really matters.
To help with that, I've published a new edition of my MySQL & MySQL HeatWave Report, covering the most important announcements around MySQL 9.7 LTS and MySQL HeatWave 9.7.
Slides: https://speakerdeck.com/freshdaz/mysql-and-mysql-heatwave-report-june-2026
PostgreSQL Autovacuum Internals and Benchmark
Vacuum, or more precisely autovacuum, is the most important automatic maintenance task in PostgreSQL. It is key for performance, but also for long-term database survival. If it runs too often, it can damage performance. If it does not run often enough, performance can suffer. With too few workers, it takes too long. With too many, it consumes resources. If the maintenance work memory is not enough, the load can multiply due to multiple index scans. If you disable it completely, it will rise from the dead and run without limits.