TPC-DS Benchmark: Trino 483, Hive 4.2 on MR3 3.0, Hive 4.2 LLAP

Since May 2023, we have been evaluating the performance of Trino and Hive on MR3 using the TPC-DS benchmark. Because all experiments have been conducted in the same cluster with the same scale factor of 10TB, they provide a consistent basis for keeping track of performance over time. Building on the previous experiment, we now expand the comparison to Trino 483, Hive 4.2 on MR3 3.0, and Apache Hive 4.2 with LLAP. This allows us to compare not only Hive with Trino, but also two execution engines (MR3 and LLAP) for the same version of Hive.

In this article, we evaluate the performance of the latest versions:

1. Trino 483 (released in July 2026)
2. Hive 4.2.0 on MR3 3.0 (released in August 2026)
3. Hive 4.2.0 with LLAP (released in November 2025)

Our goal is to present a fair and up-to-date performance comparison of the three systems under identical conditions. We refer the reader to our previous article (April 2025) for a general introduction to Trino and Hive on MR3, and to another article (July 2025) for a comparison of their architectures.

One important difference from the previous experiment is the stability issue with Trino. In the previous experiment, Trino 477 completes the entire TPC-DS query set in both sequential and concurrent tests. In contrast, Trino 483 does not complete every query in our test environment. Thus, for the sequential test of Trino 483, we run the TPC-DS benchmark three times in order to obtain at least one successful execution time for every query. For the concurrent test, we limit the concurrency level to 20 (in contrast to 40 in the previous experiment).

Experiment Setup

Cluster

We continue to use the same hardware setup. We use a cluster consisting of 1 master and 12 worker nodes with the following properties:

• 2 x Intel(R) Xeon(R) E5-2640 v4 @ 2.40GHz
• 256GB of memory
• 1 x 300GB HDD, 6 x 1TB SSDs
• 10 Gigabit network connection

In total, the amount of memory of worker nodes is 12 * 256GB = 3072GB. The cluster runs Hadoop 3.1 and uses an HDFS replication factor of 3.

TPC-DS benchmark

We use 99 queries from the original TPC-DS benchmark (generated with seed 1819994127). Each system uses queries adjusted for its SQL syntax, including differences in interval expressions and identifier quoting.

The scale factor for the TPC-DS benchmark is 10TB. We generate datasets in ORC format with Snappy compression.

In a sequential test, we submit 99 queries from the TPC-DS benchmark. We record the total execution time, the average response time, and the execution time of each individual query. For average response time, we use the geometric mean of execution times, as it takes into account outlier queries that run unusually short or long.

In a concurrent test, we use a concurrency level of 10 or 20 and start the same number of clients, each submitting queries 30 to 49 from the TPC-DS benchmark in a unique sequence. For each run, we measure the longest execution time among all clients.

Configuration

Trino runs on Java 25 (required by Trino). Hive on MR3 runs on Java 22, and Hive with LLAP runs on Java 21 (default for Hive).

We reuse the same configuration parameters for Trino from the previous experiment.

Raw data of the experiment results

For the reader's perusal, we attach the table containing the raw data of the experiment results. Here is a link to [Google Docs].

Analysis of sequential tests

Query completion

Hive on MR3 and Hive with LLAP complete all queries successfully.

Trino successfully completes 87.8 percent of all query executions across three sequential runs. Every query completes successfully in at least one run. In the analysis below, we use the shortest successful execution time for each individual query.

Correctness

The three systems return the same result for every query.

Total execution time

In terms of total execution time, Trino and Hive on MR3 exhibit practically no difference, and Hive on MR3 is about twice as fast as Hive with LLAP.

• Trino completes all queries in 3,585 seconds, down from 4,469 seconds of Trino 477.
• Hive on MR3 completes all queries in 3,588 seconds, down from 4,160 seconds in Hive 4.0 on MR3 2.2.
• Hive with LLAP completes all queries in 7,829 seconds.

Compared with the previous versions, Trino is about 20 percent faster, while Hive on MR3 is about 14 percent faster.

Average response time

In terms of average response time, Trino remains faster.

• Trino completes each query in 15.61 seconds on average, down from 17.10 seconds of Trino 477.
• Hive on MR3 completes each query in 17.11 seconds on average, down from 18.29 seconds of Hive 4.0 on MR3 2.2.
• Hive with LLAP completes each query in 26.94 seconds on average.

Analysis of concurrent tests

Query completion

Trino completes all queries at a concurrency level of 10. At a concurrency level of 20, however, Trino 483 fails to complete 66 out of a total of 420 query executions, corresponding to a failure rate of 15.7 percent.

Both Hive on MR3 and Hive with LLAP successfully complete all queries at concurrency levels of 10 and 20.

Longest execution time

In terms of longest execution time, Hive on MR3 remains faster.

• Trino completes all queries in 2,228 seconds at a concurrency level of 10.
• Hive on MR3 completes all queries in 1,594 and 3,210 seconds at concurrency levels of 10 and 20, respectively.
• Hive with LLAP completes all queries in 2,158 and 4,286 seconds at concurrency levels of 10 and 20, respectively.

The results for a concurrency level of 1 are obtained from separate runs.

Conclusions

Progress of Trino and Hive on MR3

Over the past few years, both Trino and Hive on MR3 have made steady progress in improving performance. The following graphs show the changes in total execution time since 2023 (for the 10TB TPC-DS benchmark in the same cluster).

We observe that both Trino and Hive on MR3 have achieved remarkable reductions (about 50 percent) in total execution time:

• Trino: from about 7,400 seconds to 3,600 seconds;
• Hive on MR3: from about 6,900 seconds to 3,600 seconds.

As reported in our previous article, Trino continues to lead in average response time and Hive on MR3 continues to maintain its advantage under concurrent workloads.

Hive on MR3 and Hive with LLAP

Hive on MR3 and Hive with LLAP use the same Hive query compiler, so they generate essentially the same execution plans. Below we explain the key optimizations that enable Hive on MR3 to run much faster than Hive with LLAP.

1. Avoiding unnecessary local disk I/O

MR3 reduces unnecessary local disk I/O by keeping intermediate data in memory whenever sufficient memory is available. In Apache Tez, data produced by one task is often materialized on local disk before being consumed by another task. MR3 avoids this overhead by retaining such data in memory and serving it directly to shuffle consumers. If memory becomes scarce, MR3 can still fall back to the normal disk-based path.

2. Avoiding unnecessary BytesWritable copies

MR3 reduces CPU and memory overhead by avoiding repeated copies of serialized payloads. MR3 extends BytesWritable so that a payload can be represented by a backing array, an offset, and a length. This allows MR3 to reference an existing range of bytes directly when the caller guarantees that the backing data will remain valid. On the read path, MR3 exposes backing arrays to consumers as read-only data. On the write path, MR3 can write serialized value bytes directly into the writer’s internal buffer, committing the record without copying the value again.

3. Centralizing Fetcher management

MR3 improves shuffle efficiency by centralizing Fetcher management in a central manager. Instead of allowing each shuffle input to launch and manage its own Fetchers independently, the manager tracks source hosts and running Fetchers, launching new Fetchers only when capacity is available. This centralized control also enables backpressure and congestion control, allowing MR3 to delay new Fetchers or temporarily block overloaded host.

4. Serializing VectorizedRowBatch

Hive on MR3 reduces serialization overhead by preserving the vectorized representation across the shuffle boundary. It can serialize the active rows of a VectorizedRowBatch directly, rather than extracting, serializing, and later deserializing individual rows. On the reduce side, Hive on MR3 reconstructs the column vectors directly in a new batch and passes the batch to the reducer without rebuilding the rows individually.