The latest from the MySQL community

In Part 1 we ran analytical reports in DuckDB on a DBTrail copy instead of on MySQL. This time I want to look at a different question: what if the application does not need to know the copy exists?

Most MySQL servers have a few queries that make someone wait. The monthly report that aggregates a whole table. Page 5,000 of a sorted list. The screen that reads years of history. MySQL is built for many small reads and writes, and these queries are a different kind of work.

So what happens to them with DBTrail next to the server? The same 14 reports ran for a day on a Percona Server for MySQL replica and on the copy of the same database that DBTrail keeps.

Short answer: twelve were faster on the copy, and the slowest went from 225 seconds to 7.94 seconds.

Not …

MySQL and DuckDB

Unlike row-oriented databases, which store data for a single record sequentially on disk, favoring single-row lookups, columnar databases store all the values from a column contiguously in storage, allowing only the selected column to be read from disk.

The default MySQL engine is InnoDB, which is ACID-compliant and great for OLTP (Online Transaction Processing) workloads. That said, OLAP (Online Analytical Processing) queries are built differently; they scan, group, and summarize millions or billions of rows to produce reports. In these cases, the InnoDB engine can be slow to process such queries. This has been a debt in MySQL over the years; it was common to setup ETL/CDC pipelines to export or stream the data to another engine, usually a columnar database system, to run reporting and BI queries on it.

DuckDB is a portable analytical database system, designed to be fast and reliable, similar to SQLite. …

A recent post on the MariaDB Foundation Blog has the impressive title How MariaDB 11.8 became about 3× faster on some in-memory workloads, fixing a regression dating back to 10.5.  The claim is technically correct when viewed in isolation, but I believe it becomes misleading when the broader context is taken into account.  The details are below.

The post mentions a benchmark on 11.8

Jonathan Miller has spent 27 years in database performance testing. He talks about TAF, the open source Test Automation Framework that benchmarks MariaDB, MySQL and PostgreSQL side by side, configuration provenance, and how to prove your patch made MariaDB faster.

The Man Who Benchmarks MariaDB Against the World appeared first on MariaDB.org

Thread Pool in Percona Server and MySQL (Part 2)

The previous Part 1 focused on explaining the idea of thread pool, configuration options and analysis of thread pool efficiency in Percona Server for MySQL 9.7.1-1 against the base line, which is the same server without thread pooling.

We recommend reading the post with Part 1 before proceeding with reading Part 2 in the current post.

MySQL 26.7.0 with and without thread pool:

For better understanding of Percona Server 9.7.1-1 and MySQL 26.7.0 / 9.7.2 thread pool performance against each other we will start with a brief look at MySQL on its own.

The test runs did not find any significant differences in the performance of the thread pool between …

MySQL is very good at serving application workloads, but things get more complicated when somebody decides to run a large report on the same server.

A scan can push hot pages out of the buffer pool. A long-running read can hold back purge. A GROUP BY over millions of rows can start writing temporary tables to disk.

The traditional answer is a reporting replica. But that means running another MySQL server, and at the end of the day it is still a row-oriented database.

Another option is moving the data into an analytical database. That can work very well, but now you have a data pipeline to build, operate, monitor, and eventually debug.

We have been looking at what MySQL users can do with DuckDB, and DBTrail is an interesting approach.

DBTrail is open source under Apache 2.0. It is being built by Daniel Guzman-Burgos, who previously worked at Percona as a MySQL Technical Lead.

…

Thread Pool in Percona Server and MySQL (Part 1)

A new version of Community MySQL Server July release contains two versions 26.7.0 and 9.7.2. It is an important milestone because it finally brings a Thread Pooling feature to the community. The official MySQL Server Thread Pool plugin existed for a long time, but was available exclusively for MySQL Enterprise Edition.

Before MySQL 26.7.0 / 9.7.2 the most popular free thread pooling enabled alternatives were:

• Percona Server for MySQL, which shipped Thread Pool functionality as a plugin
• MariaDB with the Thread Pooling built into the server
• Third-party plugins such as xiezhenye/mysql-plugin-threadpool available on GitHub

Now we will be able to see what benefits the thread pooling mechanism brings to MySQL Server and compare it with the implementation of the thread pool in Percona Server for MySQL.

Part 1 will explain the …

Focusing on Percona Server 8.4.11-11

My previous post (Performance Progression of Percona Server for MySQL 8.4) did a brief review of the performance changes in Percona Server for MySQL 8.4 released in 2026. I recommend reading it first to better understand the material in this post.

Version 8.4.11-11 includes patches that deliver significant improvements in performance and scalability.

One of the most impressive illustrations of the performance bump is reflected in the following graph:

Graph 1 – Percona-Server 8.4.X with 8G buffer  [ INTERACTIVE GRAPH ][ …

1. Purpose and scope

This performance investigation aims to look into the read/write performance of Percona Server for MySQL 8.4 and how it changed between versions released in 2026:

• 8.4.8-8 released on 12 March 2026
• 8.4.10-10 released on 30 June 2026
• 8.4.11-11 released on 20 August 2026

We want to see if there are improvements in scalability and performance in OLTP read/write operations, where the improvements are most noticeable and how they were achieved. For some readers this material might help with making the decision whether upgrading to a newer version is worth the effort.

An important note is that the new features or security patches will not be taken into consideration.

Measuring Latency (Percentiles) and Resource Utilization (CPU, RAM, I/O) is not in the scope of this post.

2. Configuration and Methodology

The …

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.
…