TPC-H: what the benchmark measures and how to run it

TPC-H is the decision support benchmark of the Transaction Processing Performance Council (TPC): 22 business queries and two refresh functions run against eight tables that the TPC’s dbgen program fills at a chosen scale factor, where scale factor 1 is about 1 GB. Its metric, QphH@Size, combines a single-stream power test with a multi-stream throughput test, and official results add a price per kQphH@Size. Only audited results published on tpc.org count as official; any TPC-H-style number published outside tpc.org counts as a derived workload under the TPC’s fair use rules and may not be compared with official results.

We have not run the benchmark for this guide. The facts come from tpc.org, the specification revision 3.0.1 that tpc.org lists as current, and each tool’s documentation, all checked on 1 November 2026. The judgements are ours.

What does TPC-H measure?

How fast a system answers complex analytical queries over a large dataset while new sales arrive and old ones are deleted. One specification defines the schema, the queries, the data and the rules.

The TPC-H page describes “a suite of business oriented ad-hoc queries and concurrent data modifications” (checked on 1 November 2026). The specification defines eight tables: PART, PARTSUPP, LINEITEM, ORDERS, CUSTOMER, SUPPLIER, NATION and REGION. All but the last two grow with the scale factor; LINEITEM, the largest, holds about 6,000,000 rows per unit. The refresh function RF1 inserts new rows into ORDERS and LINEITEM, and RF2 removes old sales (checked on 1 November 2026).

How is the TPC-H score calculated?

A run is a power test followed by a throughput test, and QphH@Size is the geometric mean of the two results. The price metric is the total system price divided by QphH@Size, times 1,000.

In the power test, a refresh stream runs RF1, a single query session runs all 22 queries once, then the refresh stream runs RF2. Power@Size is 3,600 times the scale factor divided by the geometric mean of those 24 timings. In the throughput test, several query streams run beside a refresh stream: at least 2 at scale factor 1, rising to 11 at scale factor 100,000. Throughput@Size is queries per hour across all streams, times the scale factor. A full test has two runs, and the sponsor reports the one with the lower QphH (all from the specification, checked on 1 November 2026).

The geometric mean weighs every query equally, so halving one query’s time raises Power by only about 3%. An official result uses a scale factor from a fixed list: 1, 10, 30, 100 and so on up to 100,000.

Who publishes TPC-H results, and which ones count?

Vendors that sponsor a test publish audited results on tpc.org, and only those count as official. Any other run is a derived workload with its own rules.

The specification requires an independent audit by a TPC-certified auditor. The TPC’s fair use quick reference allows the TPC name next to results only for official published results. Anything else needs the prefix “Derived from”, may not use the TPC metric, must carry a disclaimer that it is not comparable to published results, should disclose its environment and deviations, and may not be compared with official results (checked on 1 November 2026).

How do you run TPC-H yourself?

Generate the data and query text, load the tables, then run the power test followed by the throughput test. You can use the TPC’s own tools, a kit built for one database or an engine with a built-in generator.

The TPC’s current specifications page offers a free tools package: you register, accept a licence and get the link by email. The specification says DBGen must produce the data and QGen the query text (checked on 1 November 2026).

For PostgreSQL, the wiki’s TPC-H page gives no step-by-step procedure and points to DBT-3, a full kit that the wiki’s DBT-3 page calls a fair usage implementation of the specification. HammerDB ships TPROC-H, which its documentation calls an open source workload derived from TPC-H and not comparable to published results. It runs on PostgreSQL, MySQL, Oracle and other engines, and the docs recommend comparing the geometric mean of query times instead of calculating QphH (all checked on 1 November 2026).

DuckDB has a tpch extension that, per its documentation, implements the data generator and the queries. These lines generate scale factor 1, run query 4 and list the 22 queries:

CALL dbgen(sf = 1);
PRAGMA tpch(4);
FROM tpch_queries();

The same page warns that the data differs slightly from the specification, that each query runs with fixed parameters and that dbgen does not drop existing tables. For fully compliant data it points to tpchgen-cli (checked on 1 November 2026).

How do you read TPC-H results honestly?

Compare results only at the same scale factor and benchmark version, and read each metric with its size suffix. A chart of single query times shows neither the power test nor the throughput test.

The results page groups results by database size and carries three notes: version 2 and version 3 results are not comparable, price/performance in different currencies should not be compared, and comparisons across database sizes are misleading (checked on 1 November 2026). The specification adds that results with different stream counts are comparable at the same database size.

For an informal run, look for what the fair use rules ask for: hardware and memory, changes to schema or query text, and whether refresh functions ran. A post that times the 22 queries once on a warm cache, with no refresh stream, approximates only the query half of a power test, though such a run still helps with regression tracking. On query rate against response time, see throughput vs latency.

When should you use something other than TPC-H?

When the workload is transactional, when you want a newer analytics benchmark, or when the question is what users feel. The benchmark models one analytical workload, without short transactions or an application layer.

Choose TPC-DS for a broader decision support test: its version 4.0.0 specification uses a snowflake schema with seven fact tables and 99 queries, and its overview page says version 4 results are not comparable with earlier versions. Choose TPC-C, or HammerDB’s TPROC-C, for order-entry OLTP: the TPC-C page describes five transaction types measured in tpmC (all checked on 1 November 2026). For a quick check of one database, pgbench covers PostgreSQL and sysbench covers MySQL.

LoadFocus, which publishes this site, does not run TPC-H; its tests are aimed at web and API endpoints. It runs JMeter test plans and k6 scripts from 25 cloud regions, with no JDBC driver and no SQL module, so it cannot connect to the database. Choose a database benchmark tool such as DuckDB’s extension, DBT-3 or HammerDB instead of LoadFocus for this job, and use LoadFocus for the web or API layer in front of the database, starting from its template for the endpoints behind heavy queries.

FAQ

What is the difference between TPC-H and TPC-DS? Both are TPC decision support benchmarks. TPC-H uses 8 tables and 22 queries and reports QphH@Size, while TPC-DS uses a snowflake schema with seven fact tables and 99 queries and reports QphDS@SF.

What does QphH@Size mean in TPC-H? It is the composite queries-per-hour metric: the geometric mean of the power test and throughput test results at one database size. The suffix names that size, for example QphH@1000GB, and results at different sizes should not be compared.

Can LoadFocus run TPC-H? No. LoadFocus runs JMeter test plans and k6 scripts aimed at web and API endpoints and has no SQL connection, so use a database benchmark tool for TPC-H and LoadFocus for the application layer in front of the database.

Related reading

• pgbench: how to benchmark and load test PostgreSQL
• How to use sysbench for CPU, disk and MySQL benchmarks
• YCSB: workloads A-F, how to run it and its limits
• redis-benchmark: how to use it and read its numbers
• Throughput vs latency: how they interact under load

The technical claims in this article have not been independently reviewed.