Why StarRocks Beats Trino: A Deep Technical Comparison

Shared Foundations

Both StarRocks and Trino adopt an MPP (Massively Parallel Processing) distributed execution framework, splitting a query into many logical and physical units that run concurrently across nodes, enabling petabyte‑scale analytics and supporting hundreds of large‑scale production users.

Cost‑Based Optimizer (CBO)

Each engine embeds an efficient cost‑based optimizer, crucial for multi‑table join queries, allowing them to pass TPC‑H and the more demanding TPC‑DS benchmarks with excellent performance.

Pipeline Execution Framework

Reduces scheduling overhead of computation nodes.

Improves CPU utilization while handling queries.

Automatically adjusts parallelism to fully exploit multi‑core CPUs.

ANSI SQL Compatibility

Both support ANSI SQL, letting analysts use familiar query syntax and integrate easily with common BI tools.

Key Differences

Vectorized Query Engine

StarRocks is a native C++ vectorized engine, fully vectorizing data ingestion and query pipelines, while Trino is Java‑based with limited vectorization, resulting in StarRocks achieving 3‑10× higher CPU efficiency.

Materialized View Features

StarRocks automatically rewrites queries to use suitable materialized views without user intervention.

Supports partition‑level refresh, reducing resource consumption.

Allows materialized views to be stored on local disks using StarRocks’ proprietary columnar format.

Trino lacks automatic query rewrite and local‑disk materialized view storage.

Cache System

StarRocks provides a two‑level (memory + disk) cache with efficient disk space management, checksum verification, adaptive I/O routing, and cache pre‑warming via cache select. Version 3.3 adds adaptive cache size and TTL per object. Trino’s cache is not widely adopted.

Data Source & Open Table Support

Trino offers over 60 connectors for diverse data sources, positioning it as a unified query engine for data mesh scenarios. StarRocks focuses on query‑on‑lake workloads, supporting Apache Iceberg, Hudi, Hive, Paimon, and Delta Lake reads, with emerging write capabilities.

Benchmark Results

Using the TPC‑DS 1TB dataset on Apache Iceberg Parquet files, StarRocks achieved 5.54× faster overall query response time than Trino.

Join Performance

Both engines support complex joins, but StarRocks delivers higher performance through a richer set of join reordering algorithms (greedy, dynamic programming, exhaustive, left‑deep, associativity, commutativity) and selects strategies based on join node count, achieving optimal plans for both small and large join graphs.

High Availability

StarRocks employs stateless Front‑End (FE) nodes with Raft‑based leader election and Back‑End (BE) nodes with multi‑replica storage, enabling hot upgrades without service interruption. Trino lacks built‑in HA; its coordinator is a single point of failure.

Real‑World User Cases

Little Red Book : Migrated from Presto to StarRocks, achieving >4× query performance improvement across all concurrency levels.

WeChat : Replaced Presto with StarRocks + Iceberg, reducing query latency from minutes to seconds and improving performance 3‑6×.

Ctrip : Adopted StarRocks for lakehouse queries, gaining 3‑6× faster direct‑lake performance compared to Presto.

Beike (KE Holdings) : Using StarRocks with Hive external tables yields >3× performance gain over Presto, with >99% SQL compatibility.

Mango TV : StarRocks outperformed Trino by 2‑3× in average efficiency without enabling Data Cache.

Wanwusheng (万物新生) : Demonstrated 6.77‑10.96× performance advantage over Trino in serial and parallel tests.

Conclusion

StarRocks distinguishes itself from Trino through a native C++ vectorized engine, advanced materialized view automation, a sophisticated two‑level cache, stronger join reordering capabilities, built‑in high availability, and superior benchmark performance, making it a compelling choice for high‑performance, low‑latency analytics workloads.