SYSTEM Cited by 1 source
HammerDB¶
What it is¶
HammerDB is an open-source database benchmarking tool at hammerdb.com. It provides workload-simulation harnesses for several databases (Postgres, MySQL, Oracle, SQL Server, MariaDB, Db2, Redis, etc.) and the primary OLTP workload TPROC-C — a TPC-C-derived warehouse ordering benchmark that reports New Orders Per Minute (NOPM).
Why it shows up on this wiki¶
Databricks used HammerDB TPROC-C to measure the impact of disabling compute-side Full Page Write and moving image generation to the storage tier (per the 2026-05-07 Lakebase post). Canonical measurement:
| Compute size | Before (NOPM) | After (NOPM) | Gain |
|---|---|---|---|
| 4 vCPU | 78,876 | 94,891 | +20% |
| 16 vCPU | 95,832 | 269,189 | 2.8× |
| 32 vCPU | 95,686 | 439,300 | 4.5×+ |
The pre-change 16v→32v flat scaling (95,832 → 95,686) is the canonical signal the FPW bottleneck was capping throughput before compute did. Post-change linear scaling confirms the bottleneck was removed. (Source: sources/2026-05-07-databricks-how-lakebase-architecture-delivers-5x-faster-postgres-writes)
TPROC-C framing¶
HammerDB documents TPROC-C as "a derivative of the TPC-C specification, used for internal benchmarking only" — the results are not official TPC-C results because HammerDB does not run the full audited TPC benchmark protocol. The workload shape (warehouses, districts, customers, new-orders, payments, order-status, delivery, stock-level) matches TPC-C and produces comparable NOPM / TPM-C figures for within-deployment comparison.
Not to be confused with:
- pgbench — Postgres's built-in benchmark tool; simpler workload, different scale-factor semantics.
- systems/sysbench — general-purpose benchmark with OLTP + custom-Lua workloads; often used for comparative MySQL / Postgres write-throughput measurements.
- YCSB — Yahoo Cloud Serving Benchmark; KV-shape workload, not OLTP.
Representativeness caveats¶
TPC-C (and its derivatives) is a write-heavy OLTP workload with a specific mix of transactional patterns. Every database workload is different; a 5× improvement on TPROC-C does not imply a 5× improvement on any particular customer's production workload. Per AGENTS.md concepts/benchmark-representativeness, vendor-published benchmark numbers should be read as directionally correct rather than as production predictions.
Lakebase's 2026-05-07 post mitigates this by pairing the synthetic-benchmark numbers with production customer measurements (56 vCPU workload: WAL 30 MB/s → 1 MB/s; Synced Tables customer: 17k → 62k rows/sec), which provides cross-validation on real workload shapes.
Seen in¶
- sources/2026-05-07-databricks-how-lakebase-architecture-delivers-5x-faster-postgres-writes — TPROC-C used to measure the throughput impact of image-generation pushdown on Lakebase. First wiki-canonical reference; establishes HammerDB TPROC-C as the default Postgres-on-separated-storage OLTP benchmark in Databricks / Neon performance disclosures.
Related¶
- systems/sysbench — adjacent Postgres / MySQL benchmark tool with different workload shapes.
- systems/postgresql — one of HammerDB's target databases.
- systems/lakebase — canonical instance of a HammerDB-TPROC-C-measured performance disclosure.
- concepts/benchmark-representativeness — the general framing for interpreting vendor-published benchmark numbers.
- concepts/oltp-vs-olap — TPROC-C is an OLTP workload; HammerDB also has TPROC-H for OLAP.
- concepts/postgres-full-page-write — the write-amplification mechanism whose elimination HammerDB TPROC-C was used to measure.