MariaDB Foundation Adds PostgreSQL to Its Engine‑Agnostic Testing Framework (TAF).
The Test Automation Framework (TAF) was designed so that database makers themselves could create a plugin and integrate their database engine directly into the framework.
TAF provides the structure — lifecycle management, workload execution, profiling, reporting, and reproducible properties files — and each database plugin supplies the engine‑specific logic.
The first two plugins added to TAF were MariaDB and MySQL, proving the model: database vendors can plug their engine into TAF and immediately gain automated installs, structured workloads, concurrency sweeps, flamegraphs, and reproducible test runs.
Now, thanks to sponsor #Virtuozzo and the contribution from Virtuozzo’s employee, Lukas Oliva, TAF includes a full PostgreSQL database plugin (PR #7).
This work brings PostgreSQL into the framework as a first‑class engine with full lifecycle support, SQL execution, workload integration, and auto‑generated properties files.
Note to other database makers:
If you want your database engine included in TAF, you can build a plugin too. The framework is open, engine‑agnostic, and designed for exactly this kind of extensibility.
Before diving into the details, the Foundation would truly appreciate your input into the MariaDB Foundation: Annual Survey (Closes 10/15/2026)
Installing PostgreSQL into TAF
TAF was built so database makers can plug their engine directly into the framework. Once a plugin exists, TAF handles the rest — including automated installation of database software packages.
PostgreSQL, with some additions to install software, now fits into this model exactly the same way MariaDB and MySQL do.
The install process is fully automated: TAF validates the package, creates a staging directory, unpacks the contents, merges the required files, and moves the final install into the database_software_installs sub directory.
Running a PostgreSQL Install
A PostgreSQL install is triggered with a command such as:
TAF immediately applies command‑line overrides, validates the base package, and identifies the server‑capable by detecting the postmaster binary. If any stale staging directories are found under /tmp, TAF warns the user but does not remove them automatically — preserving forensic value for interrupted installs.
Once validation passes, TAF creates a fresh staging directory and begins unpacking the PostgreSQL. You can see TAF walking through the package contents, identifying build‑ID files, PostgreSQL include directories, and internal headers. This is part of TAF’s standard unpack‑and‑merge logic used for all database engines.
Staging, Merging, and Finalizing the Install
After unpacking, TAF merges the staged files into a unified directory structure. This
includes:
- PostgreSQL binaries
- libraries
- include files
- configuration templates
- documentation files
TAF then moves the staged install into its final location under: database_software_installs/and marks it as a valid install. The final message confirms completion:
Listing Installed Database Software
Once PostgreSQL is installed, it appears alongside MariaDB and MySQL when listing available engines:
PostgreSQL Database Plugin
With PostgreSQL support added through PR #7, TAF now includes a dedicated PostgreSQL Database Plugin.
This plugin is what makes PostgreSQL a first‑class engine inside the framework. It encapsulates all PostgreSQL‑specific behavior behind the stable TAF plugin API, allowing PostgreSQL to participate in installs, lifecycle management, SQL execution, workload runs, and reproducible properties generation exactly the same way MariaDB and MySQL do.
The plugin is a self‑contained Perl module (postgres.pm) that implements the complete PostgreSQL backend lifecycle under TAF control.
All configuration is passed at construction time, and every engine‑specific action is performed inside the plugin, ensuring deterministic behavior across packaging formats, versions, and environments.
Contributor Credit
The PostgreSQL plugin was contributed by a major Foundation sponsor Virtuozzo. Virtuozzo gave Lukas Oliva development time to produce Pull Request #7 for TAF, and is the foundation of all PostgreSQL functionality inside TAF.
Middle SQL Layer (SQL Dialects + Unified Executor)
TAF supports multiple database engines, but it does so without forcing every test suite to understand every SQL dialect. The way this works is through a middle SQL layer: a unified SQL execution system that delegates engine‑specific syntax and behavior to small, isolated dialect files.
Inside TAF, this layer lives under:
This structure is intentional.
Each engine gets its own SQL dialect file, and the Executor.pm module handles everything else — connection management, SQL dispatch, error handling, and result collection.
Test Suites
All current TAF test suites now support PostgreSQL. The PostgreSQL plugin integrates cleanly with TAF’s workload engines, allowing HammerDB, sysbench, and any SQL‑based suite to run against PostgreSQL with full automation and reproducibility.
Inside the framework, each database maker has test suite properties files under:
PostgreSQL directory includes beta properties files for each supported workload:
- hammerdb_tprocc_pgsql.properties
- hammerdb_tproch_pgsql.properties
- sysbench_lua_pgsql.properties
These properties files define the workload configuration, concurrency sweeps, profiling options, and reporting hooks for PostgreSQL runs. They are generated and managed exactly the same way as the MariaDB and MySQL equivalents, ensuring consistent behavior across all engines.
HammerDB Support
HammerDB’s PostgreSQL support is already built in.
TAF automatically generates the TCL configuration, prepares the schema, runs warm‑up and iteration phases, and collects JSON and HTML reports.
The PostgreSQL plugin handles the lifecycle, while HammerDB executes the workload through its native PG driver
This means PostgreSQL can run TPROC‑C and TPROC‑H workloads directly under TAF control, with full concurrency sweeps and reproducible properties.
Sysbench Support
Sysbench also supports PostgreSQL, but it requires one additional step: it must be compiled against the PostgreSQL installation being tested.
TAF detects whether sysbench has PG support enabled. If not, it warns and skips PG workloads.
When compiled correctly, TAF automatically builds the client, links against PostgreSQL libraries, and generates Lua workload configurations.
A typical sysbench build for PostgreSQL looks like this:
perl taf.pl –rprop=./properties/postgresql/sysbench_lua_pgsql.properties \
–action=build-client –verbose –tools-debug
From there, TAF can run any sysbench workload against PostgreSQL — OLTP read/write, point‑select, update‑index, or custom Lua scripts — with full automation and reproducibility.
Unified Behavior Across Engines
With PostgreSQL added, all test suites now share the same behavior:
- automated install and lifecycle management
- auto‑generated properties files
- unified SQL execution through the middle layer
- consistent reporting and profiling
- reproducible workloads across MariaDB, MySQL, and PostgreSQL
This is exactly what TAF was designed for — a single framework where database makers can plug in their engine, define their properties, and immediately gain full benchmark automation.
In Closing
The PostgreSQL community is encouraged to contribute test suites that focus entirely on PostgreSQL behavior.
TAF is designed as an open, engine‑agnostic framework — a place where PG‑specific workloads, profiling scenarios, and regression tests can live without needing to support MariaDB or MySQL.
Pull requests that add PostgreSQL‑only test cases, tuning profiles, or workload definitions are fully welcome.
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
