![\"\"](\"https:\/\/www.hammerdb.com\/blog\/wp-content\/uploads\/2025\/07\/slide_03.png\")
<\/a><\/p>\nHammerDB does not give legal advice, however if you run your own benchmarks on commercial databases with HammerDB and keep the results private then you are on safe ground from infringing any license conditions. There are no restrictions on any database on running benchmarks, only restrictions on sharing the results.<\/p>\n
\n
HammerDB: The Open Source Benchmarking Tool<\/h2>\n
HammerDB is a widely adopted benchmarking tool designed for relational databases. It is hosted by the TPC Council and available under the GPLv3 license on GitHub. Its cross-platform design supports both Windows and Linux clients, and Docker containers are available for simplified deployment. ARM support is also in development.<\/p>\n
Do check the HammerDB download statistics<\/a> page as HammerDB is cloned, and downloaded hundreds of thousands of times globally.<\/p>\n HammerDB supports multiple databases including MariaDB, Oracle, SQL Server, IBM Db2, MySQL, and PostgreSQL all accessed via native interfaces written in C for maximum performance and scalability.<\/p>\n HammerDB implements two primary workloads:<\/p>\n A common question is that if the workloads are based on the TPC-C and TPC-H standards then why not simply use TPC-C and TPC-H and the associated terminology such as tpmC and QphH. The answer is clear in that this terminology is copyrighted and a trademark of the TPC-Council and any tool and users using this terminology is violating these restrictions unless a workload is\u00a0 approved and published on the official TPC site. Using HammerDB you are assured that no copyright or trademarks are infringed when using or sharing (where permitted) performance data.<\/p>\n As would be expected with a database benchmarking tool, all workloads are implemented in SQL, for every workload and every database what runs in the database is SQL. For efficiency all of the HammerDB database interfaces are written in the native ‘C’ interface.<\/p>\n A key database benchmarking concept is that the tool and workload should stress the concurrency in the database and not in the client. A number of database benchmarking tools fall at this first hurdle. HammerDB is designed with low overhead and non-blocking, multithreaded parallel execution, ensuring we are stressing the concurrency control in the database and not in the client.<\/p>\n If you generate a flamegraph during a HammerDB test it demonstrates the minimal impact of the HammerDB client on system performance during TPROC-C benchmarking.<\/p>\n For OLTP tests, using stored procedures is highly recommended to reduce overhead and simulate realistic transactional patterns. This drastically reduces network round-trips and improves efficiency.<\/p>\n Another important concept that catches out many benchmarking beginners is the concept of cached vs scaled workloads.\u00a0 HammerDB always recommends starting with a cached workload, this ‘sets the bar’ for performance of\u00a0 a particular database and server.\u00a0 Advanced users can then scale an environment with HammerDB advanced features to match the cached performance.<\/p>\n HammerDB offers multiple user interfaces: a native UHD GUI for Windows and Linux, a web interface (CloudTk), and full command-line support for automation.<\/p>\n Schema creation is a streamlined process. HammerDB builds the tables, loads the data, creates indexes and stored procedures, and collects statistics with a single action. You can also perform schema checks to ensure consistency.<\/p>\n Schema builds are affected by CPU (on the client), I\/O (on the server), and network bandwidth if run remotely. For cloud-native benchmarks, it’s also possible to generate data into flat files and upload to the target system.<\/p>\n One common question is how many warehouses to configure. For most benchmarks, only a subset of warehouses are used as virtual user primarily accesses one warehouse. This keeps the data “hot” for a cached workload.<\/p>\n However, advanced scenarios like full-warehouse access allow for distributed I\/O stress testing, especially in cloud environments.<\/p>\n HammerDB supports flexible test configuration via driver scripts. These can be used to perform quick functional tests or timed runs that simulate production workloads. Test durations, ramp-up periods, and concurrency levels are easily configured.<\/p>\n While the GUI offers one-click test execution, automation for advanced users is where HammerDB excels. Using Tcl, Python, Bash, or PowerShell, entire workloads from schema creation to results capture can be scripted and run as part of CI pipelines. Docker images also enable HammerDB to be run in such environments in a self-contained environment.<\/p>\n Driver scripts offer flexible execution: quick test scripts, timed runs with ramp-up, and advanced custom options.<\/p>\n Running a test captures performance metrics and transactions over time.<\/p>\n Results are logged to a SQLite database, accessible via GUI or CLI.<\/p>\n A complete command-line test run can be built using Tcl or Python script to define connection and workload parameters and iteratively run performance profiles.<\/p>\n Each benchmark run is recorded as a job in the SQLite repository, enabling traceable, repeatable testing. HammerDB can sequence multiple jobs in an automated profile to discover scalability limits and performance plateaus. This helps expert performance engineers evaluate how well the database handles increasing user loads.<\/p>\n Job summaries and individual run details are available in the UI and exported formats, providing a clear view of performance characteristics.<\/p>\n Arguably, the most common database benchmarking error in OLTP environments is to run a single benchmark test and extrapolate the results to compare databases. This is where the performance profile is key. Automated job sequences increment virtual users to discover peak performance and scalability characteristics. Many database ‘scale’ perform and scale differently on different hardware and what may perform well on one system may not perform well on another.\u00a0 The most important metric is peak performance and advanced users often observe how closely this correlates with physical and logical CPU counts.<\/p>\n HammerDB reports two main performance indicators:<\/p>\n Job detail output provides insights into performance at individual run levels for tuning and analysis.<\/p>\n HammerDB continues to expand its capabilities. A key planned enhancement area\u00a0 is the Oracle workload replay feature, whereby Oracle trace files can be converted and run against a database for a bespoke test workload.<\/p>\n HammerDB Oracle functionality also includes an Active Session History (ASH) viewer for monitoring database performance over time. Active Session History is also supported for PostgreSQL.<\/p>\n<\/a><\/p>\n<\/a><\/p>\n\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n
\nInterfaces, Schema, and Configuration<\/h2>\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n
\nRunning Benchmarks and Automating Workloads<\/h2>\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n
\nPerformance Analysis and Result Interpretation<\/h2>\n
<\/a><\/p>\n<\/a><\/p>\n\n
<\/a><\/p>\n<\/a><\/p>\n
\nOracle Workloads and Future Plans<\/h2>\n