One of the biggest mistakes in database benchmarking is oversizing the workload until response times are measured in hundreds of milliseconds, or even seconds.

A large throughput number is not enough if the workload is already spending too long waiting. The result may look impressive at the top level, but the response times tell a different story.

The databases supported by HammerDB are all mission-critical, enterprise-class databases. At high performance, response times should be in the sub-millisecond or low millisecond range for complex stored procedures combining multiple SQL statements.

HammerDB v6.0 makes the latency profile visible.

The new response time metrics show how long individual transactions take across the run, with full percentile reporting and box plots for the key transaction types.

That means the result can show the median, higher percentiles, spread and outliers, not just an average. Averages hide too much. Percentiles show whether the system is delivering consistent low latency or whether part of the workload is already queueing behind longer waits.

HammerDB v6.0 also adds reservoir sampling for long runs. This keeps response time analysis practical even when a workload generates a very large number of transaction timings.

For long-running tests, that is important. You want the latency distribution, percentiles and outliers without turning the response time data itself into a bottleneck.

As virtual users increase, throughput and response time should be reviewed together. If throughput rises but latency moves from milliseconds to hundreds of milliseconds, the workload has crossed into overload.

HammerDB v6.0 makes that easier to see.

Run the workload. Capture the throughput. Check the percentiles. Review the response time distribution.

HammerDB v6.0 makes database benchmarking show latency as well as throughput.