The latest from the MySQL community

MySQL Security Best Practices: A Practical Guide for Locking Down Your Database Introduction

MySQL runs just about everywhere. I’ve seen it behind small personal projects, internal tools, SaaS platforms, and large enterprise systems handling serious transaction volume. When your database sits at the center of everything, it becomes part of your security perimeter whether you planned it that way or not. And that makes it a target.

Securing MySQL isn’t about flipping one magical setting and calling it done. It’s about layers. Tight access control. Encrypted connections. Clear visibility into what’s happening on the server. And operational discipline that doesn’t drift over time.

In this guide, I’m going to walk through practical MySQL security best practices that you can apply right away. These are the kinds of checks and hardening steps that reduce real risk in real environments, and help build a database …

So I figured it was about time I documented how to build persistent memory for AI agents using the databases you already know. Not vector databases - MySQL and Neo4j.

This isn't theoretical. I use this architecture daily, handling AI agent memory across multiple projects. Here's the schema and query patterns that actually work.

The Architecture

AI agents need two types of memory:

• Structured memory - What happened, when, why (MySQL)
• Pattern memory - What connects to what (Neo4j)

Vector databases are for similarity search. They're not for tracking workflow state or decision history. For that, you need ACID transactions and proper relationships.

The MySQL Schema

Here's the actual schema for AI agent persistent memory:

-- Architecture decisions the AI made
CREATE TABLE architecture_decisions (
    id INT …

Modern applications often rely on multiple services to provide fast, reliable, and scalable responses. A common and highly effective architecture involves an application, a persistent database (like MySQL), and a high-speed cache service (like Valkey).

In this guide, we’ll explore how to integrate these components effectively using Python to dramatically improve your application’s performance.

Understanding the 3-Server Architecture

In our example, the setup looks like this:

Application(172.31.68.72)
   |
   |-- MySQL client  -->  Percona Server (172.31.67.228)
   |
   |-- Valkey client -->  Valkey Server (172.31.22.118)

The Application: The brain of the system. It decides when to query the database and when to rely on cached data.

Valkey: An in-memory key-value store optimized for extremely fast reads and writes.

MySQL: The …

When a replica fails due to corruption or drift, the standard solution is to rebuild it from a fresh copy of the master when pt-table-sync is not an option. Traditionally, when we need to build a new replica, we use a physical backup for speed, but there are some cases where you still need logical backups. For instance, when you migrate to a specific vendor (i.e.: MariaDB to MySQL) or storage engines (in the past MyISAM to InnoDB and nowadays from InnoDB to RocksDB), upgrade to a new database version or move to a cloud based solution. This is where a logical backup shines, offering portability and simplicity, but only if it can be performed quickly. MyDumper emerges as the essential, modern solution, delivering the best of both worlds: the cross-platform, cross-version flexibility of a logical dump combined with the parallel, multi-threaded speed previously reserved for physical methods, making it the clear choice for rapidly rebuilding a consistent …

From Concepts to Production: Real-World Patterns, Query Plans, and What’s Next

In Part I, we introduced scoped vector search in MySQL using the MyVector plugin, focusing on how semantic similarity and SQL filtering work together.

In Part II, we explored schema design, embedding strategies, HNSW indexing, hybrid queries, and tuning — and closed with a promise to show real-world usage and execution behavior.

This final part completes the series.

Semantic Search with Explicit Scope

In real systems, semantic search is almost never global. Results must be filtered by tenant, user, or domain before ranking by …

I have a curse. My curse is curiosity. 

Here in Percona I found one person that is very “dangerous” for me, and he and I also share the same first name, well almost, Marcos Albe. 

Marcos is a smart guy with a lot of ideas, and he is not shy to share them. One day we were talking about sysbench, and he mentioned to me: you know it would be nice to have a test for joins in sysbench. I wonder why we don’t have it; it will be so useful to identify regressions in that area.
You see where this is going right? He put that in my mind, luckily I was busy with other stuff and I forgot. Until one day. That day I had to take a more in-depth look at some claims about joins performance regressions. In that moment Marcos voice comes back as an echo resonating in my mind … it would be useful to identify regressions… 

That’s it. Ok let’s do it, let’s build this joins test and see how …

1. Table(s) structure
2. The Tests
3. How to use it
4. How to modify it
   1. Method 1. 
   2. …

{index}

"What happens when you run a 10 TB MySQL database on Kubernetes?" 

That's the question many of our customers and users asked and honestly, we were extremely curious ourselves.

So, we ditched the weekend plans, rolled up our sleeves, and jumped down the rabbit hole. What we found was far more challenging (and perhaps a bit more "psychedelic") than expected. We spent days rigorously testing the Percona Operator for PXC at massive scale. 

This blog post distills all our findings into the most critical, actionable advice you need to ensure your high-scale environment not only survives but operates reliably.

If you are lazy and prefer to watch a video, here is the presentation I did at the MySQL Belgian days in January 2026. …

"What happens when you run a 10 TB MySQL database on Kubernetes?" 

That's the question many of our customers and users asked and honestly, we were extremely curious ourselves.

So, we ditched the weekend plans, rolled up our sleeves, and jumped down the rabbit hole. What we found was far more challenging (and perhaps a bit more "psychedelic") than expected. We spent days rigorously testing the Percona Operator for PXC at massive scale. 

This blog post distills all our findings into the most critical, actionable advice you need to ensure your high-scale environment not only survives but operates reliably.

If you are lazy and prefer to watch a video, here is the presentation I did at the MySQL Belgian days in January 2026.

First of …

ProxySQL 3.0.5: Security hardening, PostgreSQL protocol fixes, and smoother operations

We’re excited to announce ProxySQL 3.0.5, our first release of 2026.
As always, thank you to everyone who tested, reported issues, sent patches, and shared real-world feedback.
ProxySQL is shaped in production, and this release is a direct result of that collaboration.

ProxySQL 3.0.5 focuses on tightening security guarantees (especially for PostgreSQL TLS enforcement),
improving protocol correctness for PostgreSQL clients, and restoring compatibility knobs for MySQL
application stacks that are sensitive to version semantics.

Full release notes are available on GitHub:
https://github.com/sysown/proxysql/releases/tag/v3.0.5

What’s new in 3.0.5 (and why it matters) PostgreSQL …