MariaDB Foundation releases the BETA of the Test Automation Framework (TAF) 2.5

The MariaDB Foundation is releasing the BETA version of the Test Automation Framework (TAF) 2.5. This release represents a significant architectural upgrade, strengthening the framework’s lifecycle model, profiling capabilities, extraction and install pipeline, and reporting consistency. The focus of the BETA is on determinism, clarity, and contributor‑proof behavior across the entire workflow.

TAF continues to serve as an open, reproducible framework for evaluating MariaDB builds, running performance workloads, collecting diagnostics, and validating behavior across versions. The 2.5 BETA builds on the earlier Alpha release by refining the internal architecture and expanding the framework’s ability to support community testing.

MariaDB Foundation Releases Alpha of the Test Automation Framework (TAF)

The MariaDB Foundation is releasing the alpha version of the Test Automation Framework (TAF), an open-source benchmarking framework designed for clarity, repeatability, and vendor-neutral testing. TAF provides a structured way to run database benchmarks using consistent workloads, configuration, and reporting pipelines, making results easier to reproduce and discuss.

TAF has evolved into a modular system built around three plugin types: database maker plugins, test suite plugins, and report plugins. This architecture keeps the core stable while allowing contributors to extend the framework with new database engines, workloads, and reporting formats.

The alpha includes maker plugins for MariaDB and MySQL, test suites for Sysbench and HammerDB (TPROC-C and TPROC-H), and a set of report plugins for raw text, charts, and combined summaries.

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.