The latest from the MySQL community

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

When a commercial entity says they are working on an open source database, community members fairly ask what that means to them. They also ask if the same rules apply to everyone or just the company’s employees. Can an outsider see what's planned? Does a pull request from a stranger go through the same process as one from an employee? This blog post explores how VillageSQL approaches open source by stepping through how we are operating the VillageSQL Server project. VillageSQL Server is the open source tracking fork of MySQL that adds an extension framework to enable permissionless innovation on MySQL. 

GPLv2, inherited from MySQL

VillageSQL Server is licensed under the GNU General Public License version 2 (GPLv2), because that is how upstream MySQL is licensed and VillageSQL inherits that due to the copy left nature of GPLv2. The …

Every MySQL schema that’s been around for a few years collects indexes nobody remembers adding. Some were for a report that was retired. Some came from an ORM migration. A few were added “just in case” and never used. They all cost something: extra writes on every INSERT and UPDATE, increased buffer pool pressure, larger backups, and slower schema changes.

MySQL makes it look easy to find them. Since 5.7, the sys schema ships a view called sys.schema_unused_indexes, and one query gives you a list of indexes with zero reads since the server started. It’s tempting to turn that list straight into DROP INDEX statements.

In an earlier post, How to Find Duplicate, Unused, and Invisible Indexes in MySQL, I showed how to use that view on a single server. This post covers what that approach misses once replicas are involved.

Percona Operator for MySQL 1.3.0 is out. This release moves three things forward for teams running MySQL on Kubernetes: the operator now tunes MySQL for you based on the pod resources, async clusters can fail over without losing data in flight, and point-in-time recovery works on clusters where binary logs are encrypted at rest.

The headline features in this post are automatic MySQL configuration tuning, zero data loss failover for asynchronous clusters, and encrypted binary logs for point-in-time recovery. Each of them removes a step that teams were doing by hand, or a case they had to accept as a known gap.

As with every operator release, most of what shipped came from what the community asked for on forums.percona.com and in …

Probably everyone responsible for managing database servers at some point realizes that it would be helpful to have a tool capable of extracting data directly from raw database files. Something completely offline, without the need to have a running database server, and that would work with data directories, files, or binary backups (storage volume snapshots, XtraBackup, etc).

There are a couple of use cases for that I could think of:

• Crashed/corrupted data recovery – if the database service refuses to start or enters a crash-restart loop and there are no good backups (PITR!) available.
• Backup (additional) verification and data files health check.
• Extraction of individual databases or tables from a full backup.
• Quick provisioning of staging/QA instances …

I opened my MySQL BR Conf 2026 talk creating a new data type that stock MySQL doesn’t have: ROT13. … OK, admittedly, it’s a silly type. With a ROT13 column, you insert plain strings and read back plain strings, but the table stores scrambled text. … OK, it’s very *very* silly. But the point of this example isn’t to convince you extensions are useful; it’s to show a tiny extension that allows exploring design choices we made in designing the VEF (VillageSQL Extension Framework).

What the talk covers

• Simpler functions and aggregates. VDF’s (VEF-Defined Functions) resemble MySQL UDF’s (User-Defined Functions), but are easier to write. I explore how we made it both more ergonomic in C++ and also how we make it harder to mess up.
• Types …

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

On paper it’s a boring release. No new tools, no new flags, nothing to reconfigure. In practice it’s one I’m glad I didn’t skip: it closes 37 known vulnerabilities that the server could actually reach, and I found them more or less by accident.

It started as a compatibility check

I had MySQL 8.4, 9.7 and 26.7 running on my test box, plus MariaDB 12.3. So I pointed the MCP server’s test suite at all of them. Mostly to tick a box before moving on to something more fun.

The code was fine. Every version passed.

MySQL 26.7 and MariaDB 12.3 join the matrix

Every pull request now runs the full integration suite against six servers:

• MySQL 8.0, 8.4, 9.7 and 26.7
• MariaDB 11.4 and 12.3

26.7 is the first Innovation release under Oracle’s new calendar versioning. If you follow MyVector, you know I’ve …

As businesses grow, their databases must support both fast transactions and timely analytics. OLTP workloads handle everyday operations such as orders and payments, while OLAP workloads analyze large datasets for reporting and planning. Without appropriate optimization, growing data volumes and competing resource demands can slow transactions and delay insights. MySQL HeatWave supports online transaction processing […]