MariaDB Foundation: TAF Now Supports Embedded Database Configuration in User Properties

Written by Written by Jonathan Miller Leave a comment on MariaDB Foundation: TAF Now Supports Embedded Database Configuration in User Properties

TAF: One File to Rule Them All

In a one‑on‑one review of TAF with Monty Widenius, the creator of MySQL and MariaDB, he looked at me and said: “I want everything in one user file.”

It was simple, direct, and completely right direction.

TAF’s configuration model had inherited its design from older frameworks — a user properties file and a separate database configuration file.

Monty’s comment cut straight through it. He wanted simplicity — one file that defines everything.

So in design of I didn’t throw out the old design; I combined it.

The result is a cleaner, unified configuration model that still respects the original architecture.

Before diving into the details, the Foundation would truly appreciate your input into the MariaDB Foundation: Annual Survey

Three Ways to Provide Database Configuration

TAF still supports all existing methods, but now they have a clear and predictable ranking:

1. Lowest Priority: External db_config_file

Defined in the user properties:

    taf.db_config_file=/path/to/config.cnf

This still works exactly as before.

If nothing else overrides it, this file becomes the database configuration.

2. Middle Priority: Inline DB Configuration Block

You can now embed the configuration directly inside the user properties file:

This inline block overrides any taf.db_config_file referenced in the properties.

3. Highest Priority: Command Line Override

CLI always wins:

    --db-config-file=/path/to/config.cnf

Just like all other CLI arguments, this takes precedence over everything in the properties file.

How TAF Handles the Winning Configuration

No matter which source wins — taf properties, inline block, or CLI — TAF does the same thing:

  1. Generates a temporary database configuration file containing the winning settings.
  2. Uses that file to initialize and start the database.
  3. Stores the generated configuration file inside the results archive.

This solves multiple problems at once:

  • No more config drift.
  • No more “which file did this run actually use?”
  • No more missing configs in archived results.
  • Every test case is fully reproducible from a single file.

Why This Matters

Monty’s “one file” idea wasn’t just convenience — it was clarity. For users like him, and for anyone who wants clean, self‑contained test definitions, this change eliminates friction:

  • One file can define the entire test.
  • The database configuration travels with the properties.
  • The archived results always include the exact configuration used.
  • Reruns become trivial: just point TAF at the autogenerated test case properties file.

This closes a design gap that’s bothered me for a long time and makes TAF test cases cleaner, simpler, and easier to reason about.

Next Blog Preview: Auto‑Generated User Properties for Full Test Reproduction

The next blog will cover one of the most important pieces of TAF’s reproducibility story: the auto‑generated user properties file.

Every time TAF runs a test case, it now produces a self‑contained, fully resolved user properties file that includes:

  • the winning database configuration (from CLI, inline block, or external file)
  • all resolved test parameters
  • all environment‑specific values
  • all runtime decisions
  • everything needed to reproduce the test exactly

This file is created automatically every run and stored inside the results archive. It’s the final piece that guarantees test case reproducibility — no guessing, no missing configs, no “what did this run actually use?” mysteries.

The next blog will walk through how this file is generated, what it contains, and how it makes TAF test cases fully portable and future‑proof.

Hardware Sponsor Acknowledgment — Hetzner.com

TAF 4.0 was engineered and validated on high‑performance hosts provided by Hetzner.

hz-bench

  • Intel i5‑13500 (20 vCPUs / 14 cores)
  • 62 GB RAM
  • AlmaLinux 9.7

hz-bench2

  • AMD EPYC 9454 (96 vCPUs / 48 cores)
  • 125 GB RAM
  • AlmaLinux 9.8

These systems enabled full multi‑database workload testing, reproducible performance runs, and the scale required to expose real behavior across MariaDB, MySQL, and PostgreSQL.

We appreciate Hetzner’s outstanding support.

Reminder:

TAF now supports MariaDB, MySQL and PostgreSQL.

In Closing

To all database vendors, please take TAF performance testing framework and use it.

The MariaDB Foundation released it openly because performance change detection should benefit the entire database ecosystem, not just one project.

Users deserve predictable performance, and TAF exists to make that possible for all.

Jonathan (Jeb) Miller has experience in military leadership, Fire/EMS leadership, computer operations leadership, teaching, and more than 27 years of database performance engineering (PervasiveSQL, MySQL, MariaDB).

TAF is the third benchmarking framework he has helped design and build.

#MariaDB #MySQL #PostgreSQL #Database #DatabasePerformance #Performance #Hetzner