MariaDB Foundation Advances TAF with HammerDB 6.0 and xt_reservoir Integration

Overview

While validating MariaDB RSS stability under stored procedure workloads, I ran into unexpected memory growth. The goal was straightforward: confirm that MariaDB was not leaking memory when running TPROC-C stored procedure workloads. To do this, I used HammerDB TPROC-C SP and added improved RSS monitoring so I could watch memory usage over long-duration runs.

The results were clear. MariaDB RSS stayed stable. HammerDB 5.0 kept growing, and growing.

This led to a deeper investigation into HammerDB itself, and ultimately to an update in TAF to support HammerDB 6.0 and a new RSS logging script.

A response to Percona’s 2026 MySQL ecosystem benchmark: useful data, but not a realistic MariaDB comparison

Percona’s new 2026 benchmark report is interesting because it puts several MySQL-family releases on the same graphs and shares a public repository for the test harness. That openness is welcome. But after reading both the article and the published scripts, I do not think the post supports broad conclusions about “ecosystem performance,” and I especially do not think it represents an adequately tuned MariaDB, worthy of a neutral comparison.

Versions

The versions chosen for MariaDB are already a subject of debate. MySQL 9.6.0 (the latest Innovation Release) and MariaDB 12.1.2 (a rolling release) were used.

MariaDB Innovation: InnoDB-Based Binary Log

I am starting a new series on what makes MariaDB Server distinct from MySQL, highlighting innovations that make the difference.

MariaDB 12.3 introduces a new binary log implementation that stores binlog events directly in InnoDB-managed tablespaces rather than in separate flat files on disk.

This is an incredible innovation; for a long time, binary logs have been a performance bottleneck. DimK pointed it out several times. [1], [2]

The new binlog design halves the number of fsyncs and improves performance, as Mark Callaghan noted in his blog posts.

Big Vector Search Benchmark: 10 databases comparison

I have benchmarked MariaDB Vector before, but it was a while ago. Users kept asking about Milvus. New pgvector alternatives were gaining popularity. And I simply wanted to see if MariaDB got any better. This benchmark round includes more databases, larger dataset, and no irrelevant datasets that only add noise but don’t really help today in 2026.

Dataset

Now is the AI time. Vector search is used for embeddings generated by LLMs. Most ann-benchmarks datasets are pre-AI and use, for example, image transformations and filters to construct vectors. While useful for certain purposes, they are not the main use case for the MariaDB Vector and providing these results would be misleading and distracting from what matters to users.

The Real Operational Cost of Vacuuming in PostgreSQL

There was a time when PostgreSQL’s own developers were far more open about the real cost of their MVCC design. Back in the 8.1 era, the documentation spelled out the resource drain, the vacuum overhead, and the “cold comfort” of wraparound risk in plain language. I first read that line in 2003, and it stuck with me for more than twenty years. I could not imagine any serious operations team wanting a database that required a separate background process to clean up transactions long after they had completed. PostgreSQL has absolutely improved vacuuming — autovacuum, visibility maps, HOT updates, parallel vacuum, better defaults, better alerts.

Why sysbench‑tpcc results on outdated hardware should not be presented as a valid OLTP vendor comparison

Benchmark results only have meaning when the workload, hardware, and methodology are clearly defined and reproducible. When those elements are unclear or incomplete, the conclusions can easily mislead readers into assuming the results represent something they do not. 

That is the core issue with the recent Percona post comparing MySQL, Percona Server, and MariaDB.

This is not about disputing Percona’s numbers. Their results may be valid for their environment. 

The problem is that the post presents the results in a way that implies a valid OLTP vendor comparison, while the underlying methodology and hardware make such a comparison impossible to support.

Open Source Performance, Benchmarks and MariaDB: A Conversation with Steve Shaw

Right after the recent MariaDB Meetup in London, I had the pleasure of sitting down with Steve Shaw – founder and CEO of HammerDB, former Principal Engineer at Intel, and board member of the MariaDB Foundation. Steve delivered the keynote talk at the event and has a unique perspective on performance, open source, and the intersection between commercial and community-driven database development.

This blog post captures our conversation – a dialogue between two people passionate about open source and database performance. We talk about Steve’s transition from Intel to HammerDB, his relationship with MariaDB Corporation, the nuances of performance testing, and what lies ahead for the HammerDB and MariaDB communities.

Tempesta Technologies Becomes Silver Sponsor of MariaDB Foundation

We are delighted to welcome Tempesta Technologies as a Silver Sponsor of the MariaDB Foundation!

Tempesta Technologies is the developer of Tempesta FW, an open-source hybrid of a web accelerator and a multi-layer firewall. Engineered for maximum efficiency, Tempesta FW is tightly integrated with the Linux TCP/IP stack and leverages cutting-edge technologies to deliver exceptional web application performance. It provides robust protection against DDoS and web attacks while ensuring smooth, high-speed operation under normal conditions.

This partnership underscores MariaDB Server’s continued commitment to performance and efficiency—not just in terms of database speed and scalability, but across the broader ecosystem that powers modern web infrastructure.