The following release notes describe the changes in HammerDB v6.1.
HammerDB v6.1 adds VillageSQL as a separate MySQL-compatible database engine for TPROC-C and TPROC-H, native Linux ARM64 (aarch64) support, modernised Web Service Jobs and Pipelines interfaces, and further CI automation and workload improvements. It also adds TLS connection improvements for MySQL, MariaDB and VillageSQL, and new MariaDB TPROC-C stored procedure implementations.
Linux ARM64 support extends HammerDB to native Arm systems in addition to x86-64. The multi-architecture Docker packaging introduced alongside the 6.0 builds supports linux/amd64 and linux/arm64.
Database engines: VillageSQL TPROC-C and TPROC-H workloads and VillageSQL CI provider; Azure Citus/Elastic Cluster connection and load-balancer port support for PostgreSQL TPROC-C.
Connections and transactions: MySQL-family one-way TLS without explicit CA files; set-based MariaDB New Order and Delivery with automatic fallback; conditional MariaDB UPDATE RETURNING INTO support; Percona Server for MySQL identification in results.
Builds and automation: native ARM64 Bawt builds; external CI configuration discovery and override persistence; CPU-scaled profile virtual-user increments and capped virtual users for very large schema builds; VillageSQL Tcl and Python automation scripts.
Web Service and usability: redesigned light/dark Jobs, Pipelines, Help and benchmark report pages; more consistent pipeline navigation and job deletion; flat desktop GUI menus on Linux and Windows.
Defaults and correctness: increased TPROC-C total iterations default to 2147483647 and fixes for PostgreSQL rollback/vacuum, MySQL-family generated errors and connection pools, Windows BCP certificate handling, Active Session History wait attribution, I/O metric aggregation, CPU reporting, job timing, graph clipping, pipeline profile IDs, and metrics agent disconnects.
Individual changes and implementation details are recorded in the HammerDB pull request history. The following chapters describe new user-facing functionality; maintenance fixes do not each require a separate procedure or screenshot.
When upgrading directly from HammerDB v5.0 to v6.1, remove or back up the old HammerDB persistent configuration database files before starting the newer version for the first time. This legacy migration step is not a requirement to delete job history when upgrading from HammerDB v6.0 to v6.1.
HammerDB stores persistent configuration and job information in SQLite database files. These files commonly use the .db and .DB file extensions and are stored by default in the operating system temporary directory, unless the location has been changed in the HammerDB configuration. For a direct v5.0 upgrade, removing the old configuration files enables v6.1 to create configuration databases with current defaults.
On Linux, the default temporary directory is usually /tmp. On Windows, the temporary directory is usually the directory referenced by the TEMP or TMP environment variable. If a custom SQLite database directory has been set in the HammerDB configuration, remove the HammerDB .db and .DB files from that configured directory instead.
Only remove HammerDB configuration and job database files that are no longer required. If existing job history needs to be retained, copy the files to a safe backup location before removing them from the active HammerDB temporary directory.
After the old files have been removed, start HammerDB v6.1. HammerDB will create new persistent configuration and jobs database files automatically.