GaussDB reported a composite TPC-H score of 39,508,107 on a 30 TB run, a figure the paper says was 40% higher than Hologres. But the result comes from an arXiv preprint whose authors say the TPC-H results were still unaudited.
The headline number combines two parts of the benchmark. GaussDB's reported power-test score was 39,269,930.7, while its throughput-test score was 39,747,729.1. The paper reports the composite as 39,508,107.
A demanding test, plus smaller component checks
The main evaluation used TPC-H scale factor 30,000, representing 30 TB, on 32 BMS servers. The setup had 128 data nodes, 64 TB of total memory and 5,120 CPU cores. The study also paired that end-to-end test with component microbenchmarks, examining both the whole system and selected parts of it.
On the power test, the authors say GaussDB performed best on most individual queries and was generally similar to the best-performing system on the rest.
The paper also gives a per-vCPU comparison. GaussDB's composite figure was 7,716, against 2,533 for Hologres. Exasol was highest at 9,837. The comparison therefore presents the overall score and the score adjusted for processor count as different views of performance.
What the smaller tests measured
One change was a pipeline execution engine. It uses pull execution within a pipeline and push execution between pipelines. In a single-node 100 GB TPC-H Q21 test at a degree of parallelism of 32, the pipeline engine was 28% faster than the Volcano engine.
For data movement, GaussDB used a two-level-mailbox design. It manages quotas at the data-node level and reduces the number of communication channels compared with a flat mailbox. In a Q9 test using 32 data nodes, 7.5 TB and a degree of parallelism of 32, the paper reports a 26.89% elapsed-time improvement over the flat design.
The network comparison was less uniform. In an eight-node TPC-H test at scale factor 7,500, or 7.5 TB, UB communication was 7.18% higher overall than TCP, but a subset of queries ran worse.
The Bloom-filter work extended support from single-node systems to distributed MPP-SMP deployments and included the cost of streaming filters between data nodes during cost-based optimization. Across the tested MPP scales, BF-POST was associated with an approximate 20% to 40% reduction in overall execution time compared with using no Bloom filters. BF-CBO was associated with an approximate 50% to 60% reduction.
Another test looked for near foreign-key relationships, or near-FK constraints, using HLL synopses, compact summaries used for approximate comparisons. The detector ran in tens to hundreds of microseconds. In join clauses from the 7.5 TB deployment, it found zero reported false positives and zero reported false negatives.
At 7.5 TB, the IMCV compression test reduced approximate in-memory size from 10 TB to 4 TB, or 60%, with a negligible reported difference in end-to-end latency.
A result that still needs checking
The central result is a report on an integrated stack of changes. Because the evaluation combines component microbenchmarks with an end-to-end TPC-H run, the 30 TB score does not by itself show how much any one change contributed.
The same caution applies to the system comparisons. GaussDB's reported scores were generated on the stated benchmark configuration, while the paper presents Hologres and Exasol figures as comparison points. Since the document is an arXiv preprint and the authors say the TPC-H results were unaudited, the numbers are best read as reported benchmark results pending audit.
The next useful test would be to reproduce the 30 TB benchmark under audited conditions and separate the contribution of the individual changes. Until then, the paper offers a detailed set of engineering results and a striking headline score, but its evidence remains tied to the configurations it measured.
Paper data and sources
Original title: No Silver Bullet: Boosting GaussDB Performance on the 30TB TPC-H Workload
Authors: Tim Zeyl, Jason Lam, Shu Lin et al.
Journal/Repository: arXiv
Status: Preprint, not yet peer-reviewed
First online: 2026-08-28
DOI: 10.14778/3827998.3828014
Original paper · Full text