Blog

StarRocks 4.1: Built for Production, Designed to Simplify

Kate Shao — Wed, 29 Apr 2026 07:17:54 GMT

StarRocks Monitor & Alert Guide_Part 3: Application Availability

Kate Shao — Tue, 21 Apr 2026 22:00:00 GMT

Designing an Analytics Engine for AI Agent Workloads

Kate Shao — Tue, 07 Apr 2026 08:11:29 GMT

✍🏼 About the Author:

Kaisen Kang , StarRocks TSC Member, Query Engine & AI Agent Team Lead at CelerData

How to Manage Schema Migrations in StarRocks with SQLAlchemy and Alembic

Kate Shao — Tue, 31 Mar 2026 06:33:09 GMT

StarRocks Monitor & Alert Guide_Part 2: Cluster Service Health

Kate Shao — Tue, 24 Mar 2026 07:09:50 GMT

StarRocks Monitor & Alert Guide_Part 1: Resource Saturation

Kate Shao — Mon, 16 Mar 2026 15:30:00 GMT

In day-to-day operations, unexpected issues pop up all the time. One moment everything is running smoothly, and the next you're scrambling to figure out why queries are timing out or nodes are suddenly under heavy load. Many teams end up stuck in a constant cycle of reacting to incidents and “putting out fires.”

Deep Dive: How StarRocks Built a High-Performance Vectorized Engine

Kate Shao — Tue, 24 Feb 2026 19:00:00 GMT

✍🏼 About the Author:

Kaisen Kang , StarRocks TSC Member, Query Engine & AI Agent Team Lead at CelerData

DataOps-Driven Governance and Analytics with dbt and StarRocks

Kate Shao — Thu, 12 Feb 2026 11:50:29 GMT

✍🏼 About The Author:

Author: Jacky Wu is a dbt-starrocks contributor and Senior Enterprise Solution Manager at SJM Resorts. He specializes in enterprise data architecture, DataOps practices, real-time analytics, and works closely with engineering and business teams to deliver scalable, governance-ready data platforms.

As enterprises increasingly rely on data to drive real-time decision-making, traditional data architectures and development workflows are struggling to keep pace with growing demands for speed, reliability, and governance. This article explores how a modern, integrated data architecture, built on dbt, StarRocks, and DataOps practices, addresses these challenges by unifying data modeling, automation, and analytics into a single, cohesive framework.

Through a combination of engineering best practices and platform innovation, this “three-in-one” approach enables faster iteration, stronger governance, and more reliable analytics across both real-time and batch scenarios. The discussion unfolds across four key dimensions: the role of dbt in data modeling and governance automation, the impact of DataOps on agility and control, StarRocks' technical breakthroughs for hybrid analytics, and real-world case studies that demonstrate these capabilities in practice.

The Core Role of dbt in Data Modeling and Governance Automation

Key Capabilities of dbt

At its core, dbt is a framework for building and governing analytics data through code. Raw data processed with dbt is transformed according to the principle of “data models as code,” allowing teams to define transformations, logic, and dependencies in a structured, version-controlled way. Beyond generating curated data models, dbt also produces essential governance artifacts, including data dictionaries, lineage graphs, and automated data quality tests.

With these foundations in place, dbt serves as the backbone for developing a wide range of data products—from analytical dashboards to data-driven applications that directly support business workflows.

At the methodological level, dbt introduces a core concept that closely aligns with DevOps. Most engineering teams are already familiar with DevOps, which focuses on managing and collaborating on code through standardized, engineering-driven practices. dbt extends this philosophy into the data domain, applying the same engineering rigor to data development and governance.

Data Models as Code

In practice, teams typically work across multiple feature branches, with automated tests triggered during the merge process. Once changes are validated in a staging environment, CI/CD pipelines are used to promote them into production. This workflow allows data models to be versioned, reviewed, and managed with the same discipline and rigor as application code.To make this model effective in real-world analytics systems, it needs to be paired with an execution engine that can support both high-performance queries and frequent model changes. This is where the analytical database layer becomes critical.

StarRocks as the Analytical Execution Layer

StarRocks is a high-performance analytical database designed for modern, real-time analytics workloads. It follows a lakehouse-oriented architecture, enabling unified analytics across both real-time and batch data without maintaining separate systems for streaming and offline processing.

StarRocks supports high-concurrency, low-latency queries directly on fresh data, making it well suited for dashboards, operational analytics, and data-driven applications. At the same time, it integrates naturally with data lakes and ELT pipelines, allowing teams to build scalable analytics platforms without sacrificing performance or consistency.

In this architecture, StarRocks serves as the analytical execution layer where raw data is continuously ingested and stored, while dbt operates on top of it to define transformations, models, and governance logic. Together, they form a clean separation of responsibilities: StarRocks focuses on efficient data storage and query execution, while dbt manages modeling, version control, and testing.

Within this setup, dbt integrates seamlessly with ELT workflows, improving the efficiency, reliability, and overall controllability of data modeling and governance. In day-to-day development, when issues are identified in a specific data model, teams can quickly roll back changes at the branch level. With Git as the system of record, every change goes through code review and is deployed via automated CI/CD pipelines.

As a result, SQL models, materialized views, and other data objects are promoted to production through standard pull request (PR) workflows, ensuring consistency, traceability, and operational safety across the entire lifecycle.

dbt also integrates seamlessly with the native StarRocks ecosystem, enabling version control across multiple types of data objects, including tables, views, materialized views (MVs), and tasks. In dbt, a model is essentially a SQL template. A typical pattern is to first create a staging model for customer data, then reuse it as a dependency for downstream custom business models. dbt automatically resolves dependencies between models and manages execution order, eliminating the need for external scheduling tools—running dbt alone is sufficient to orchestrate the entire pipeline.

Automated Data Dictionary Generation

From a documentation and asset management perspective, dbt can automatically generate data dictionaries and other documentation artifacts. Through dbt-generated HTML documentation, teams can easily explore field definitions, business meanings, underlying SQL logic, and upstream/downstream dependencies. The documentation interface can also be customized with enterprise branding, including logos and visual styles.

Automated Data Lineage

Data lineage is a foundational component of any data governance framework. Large enterprises often manage thousands of tables and a vast portfolio of data products. In industries such as hospitality, where organizations operate across hotels, restaurants, and other business lines, it is common to build a unified Customer 360 view to consolidate data assets across domains.

In these environments, even small changes to upstream raw data can have far-reaching effects. A core challenge is quickly identifying which downstream models, reports, or data products may be impacted. Data lineage addresses this need by enabling precise impact analysis, giving teams clear visibility into dependencies and helping them assess the scope and risk of upstream changes or data quality issues.

Automated Data Quality Testing

Beyond data lineage, automated data testing is a core pillar of dbt best practices. Teams can define a wide range of automated tests for their data models, such as scheduled daily validations to ensure that datasets continue to meet expected conditions. When anomalies are detected, alerts can be triggered immediately, enabling faster detection and resolution of data issues.

From an implementation standpoint, dbt model configurations are typically defined in YAML files. Each model includes metadata such as its name and description, which capture the model's purpose and business context, followed by field-level definitions. dbt provides a comprehensive set of built-in tests, such as unique and not_null to enforce common data quality constraints, including uniqueness and null checks.

In most OLAP databases, foreign key constraints are not enforced at the database level. To address this gap, dbt offers ref-based and relationship testing capabilities, allowing teams to validate that models are correctly referenced by downstream tables or models. These tests are also centrally managed through YAML configuration files.

In practice, some teams further enhance this workflow by using AI-assisted tools to automatically generate and batch-maintain YAML configurations, significantly reducing manual effort while improving consistency.

How DataOps Workflows Improve Agility and Control in Data Projects

Key Components of DataOps

Building on the principles of DevOps, DataOps extends the same engineering mindset into the data domain. In application development, DevOps has become the standard approach for managing code development, integration, and deployment. DataOps applies these proven practices to the full data lifecycle, from development, testing, deployment, and ongoing operations to improve both speed and reliability.

In a typical DataOps architecture, the areas covered by dbt are often clearly highlighted. These include data modeling, automated data quality testing, data lineage analysis, and documentation-driven validation—all of which are native capabilities of dbt. For stages beyond dbt's scope, teams typically integrate other well-established tools to complete the workflow. Project management platforms such as Jira is used to track model changes and defects; scheduling tools manage periodic model execution and data checks (hourly or daily); CI/CD tools like Jenkins handle automated integration and deployment; and downstream analytics and BI tools support data consumption, visualization, and decision-making.

Version Control Standards: Conventional Commits

At the version control layer, experienced teams typically adopt a standardized commit convention. One widely used approach is Conventional Commits, which defines a structured format for commit messages. Its core idea is to clearly distinguish between different types of changes, such as feature enhancements and bug fixes, so that versioning and release management can be automated.

For example, when a change introduces new functionality, such as adding a new dimension to an order model, the minor version is incremented (e.g., from 2.0 to 2.1). These changes are generally backward compatible. In contrast, bug fixes only trigger a patch version increment (e.g., from 2.1.0 to 2.1.1).

Conventional Commits also make it possible to generate release notes automatically. In the past, release managers often had to manually confirm changes with developers and compile release notes by hand—a process that was both time-consuming and error-prone. With Conventional Commits in place, this workflow can be fully automated.

When commit messages follow the defined convention (for example, using the fix prefix), they can be automatically parsed and aggregated into structured release notes. Developers focus on writing clear, standardized commit messages, while the tooling handles release note generation. As part of the CI/CD pipeline, release notes are created and updated automatically with each release, requiring no additional manual effort from the team.

A CI/CD Automation Example in DataOps

In a DataOps framework, the CI/CD workflow typically starts with a Pull Request (PR). Every change is introduced through a PR, which triggers a standardized validation and deployment pipeline.

The pipeline begins with automated code quality checks, commonly referred to as linting. Similar to style and syntax validation in application development, linting tools automatically analyze SQL models and related configurations to ensure they conform to predefined standards. Once these checks pass, the changes are deployed to a staging environment.

Using dbt as an example, individual models can be deployed to specific environments. This makes it possible to deploy a single model to staging and run targeted unit tests and data quality checks. After the automated tests pass, the workflow moves to a manual review stage, where reviewers examine the PR to validate the logic and assess its potential impact.

Once the changes are approved and merged into the main branch, the system automatically packages a new version, updates the change history, and promotes the release to QA or production environments. This end-to-end process ensures that data changes are delivered with both speed and control—key characteristics of a mature DataOps practice.

Technical Breakthroughs with StarRocks for Real-Time and Batch Analytics

Traditional Siloed ETL Architectures in Lake–Warehouse Separation

In early-stage implementations, many teams relied on siloed ETL architectures. Using a hospitality industry scenario as an example, the initial setup typically consisted of multiple independent operational databases at the source layer. ETL jobs ran on fixed schedules (for example, every 15 minutes) to extract data from these systems and load it into multiple data warehouses. In parallel, separate data pipelines were built to support mobile applications, reporting systems, and other analytical workloads.

This architecture came with several fundamental limitations. Data models lacked version control, making the system fragile and easy to break as changes accumulated. Testing was largely manual, which made it difficult to establish a consistent and repeatable quality assurance process. Documentation was also highly fragmented, often maintained as standalone Word files across different teams, resulting in poor consistency, limited traceability, and high maintenance overhead.

The StarRocks ELT Framework

With the introduction of StarRocks as an integrated platform, the overall architecture was redesigned into a unified lakehouse model that supports both real-time and batch processing. Using real-time CDC, data from multiple operational systems is continuously ingested into the data lake. On top of the lakehouse, an ELT-based framework enables rapid construction of application-facing data products.

At the same time, data governance capabilities are implemented end-to-end across the pipeline. Version control is established around data models, data dictionaries are centrally maintained, and data lineage views are generated through tooling, providing full visibility into dependencies and impact.

Results from StarRocks + dbt + DataOps in Practice

In the re-architected system, near-real-time data simultaneously supports mobile applications, reporting dashboards, and behavioral analytics workloads. On top of this foundation, a unified “three-in-one” DataOps framework delivers several immediate and measurable benefits:

Faster iteration and recovery. Data models built with dbt can be updated and rolled back quickly, significantly improving development velocity and incident recovery time.
More efficient delivery through standardized pipelines. DataOps manages business requirements and data product delivery through well-defined pipelines, introducing Agile-style practices that standardize project management workflows and automated release cycles. This substantially shortens the end-to-end lead time from requirement definition to production.
Strong consistency between models and documentation. Model definitions and their corresponding YAML files are version-controlled together in Git, creating a single source of truth. Any model change requires the related documentation to be updated; otherwise, the release pipeline will fail validation.
Higher analytical accuracy and reliability. For enterprises operating dozens of hotel systems, data lineage analysis makes it possible to understand where a system sits within the overall data pipeline and to assess downstream impact before upgrades. In parallel, automated data testing performs continuous health checks on models, validating data correctness and alignment with expectations on a daily basis。

Escaping the Small-File Trap: How StarRocks Optimizes Bulk Ingestion

Kate Shao — Thu, 29 Jan 2026 06:36:44 GMT

✍🏼 About The Author:

Casey Luo, StarRocks Committer & Engineer at Celerdata

TL;DR

Under the storage–compute separation (shared-data) architecture, one-time ingestion of massive historical datasets has become an amplified but often overlooked risk. This article explains how StarRocks rethinks the large-scale ingestion path at its source. By redesigning the write pipeline, from memory → local disk spill → centralized merge → object storage, StarRocks minimizes remote writes and redundant overhead, significantly reduces the number of S3 write operations, and improves write throughput by fully utilizing local I/O capacity. This approach addresses the small-file problem at its root, enabling higher efficiency and stability at a lower overall cost.

Note: This optimization is available starting with StarRocks 3.5 and does not apply to earlier versions.

Large-Scale Ingestion Becomes an "Amplified Problem" in Shared-Data Architecture

As more users migrate large volumes of historical data into StarRocks, one-time bulk ingestion has become a common operational pattern. On the surface, this looks like a straightforward offline data load. In practice, however, under a shared-data architecture backed by object storage, improper handling can easily trigger a chain reaction: degraded ingestion performance, explosive growth in small files at the storage layer, and ultimately impaired query performance.

As a distributed columnar database, StarRocks adopts an LSM-tree–like storage model. Newly ingested data is first written into in-memory memtables. After sorting and other processing, background threads flush these memtables to persistent storage, and subsequent compaction merges multiple small files into larger, ordered ones. Under normal incremental write workloads, this design balances write efficiency with query performance effectively. But when ingesting massive volumes of historical data in bulk, the same mechanisms can become a bottleneck—and the issues are significantly magnified:

Huge data volumes and many tablets. Historical datasets often span a large number of tablets. Each tablet maintains its own memtable, and under high-concurrency ingestion, memtables are flushed frequently, generating a large number of small files in a short time.
Limited compute resources during ingestion. In shared-data architecture deployments, users often start with a small number of compute nodes (CNs), sometimes even a single CN, with modest CPU and memory. These constraints further exacerbate the pattern of small memtables, frequent flushes, and rapid accumulation of small files.
Early scale-down after ingestion. One advantage of storage–compute separation is the ability to scale down or release compute resources immediately after bulk ingestion, retaining only the data in object storage to reduce costs. However, this also means that the large number of small files generated during ingestion may never be sufficiently compacted, leaving long-term fragmentation in the underlying storage.
Query performance degradation later on. When the cluster is scaled back up and queries are run against these historical datasets, the need to scan and process a vast number of small files can significantly degrade query performance.

In short, these issues are more pronounced in storage–compute separation environments because users naturally favor completing large historical ingestions with minimal, lower-spec compute resources. This choice amplifies the small-file problem, which then cascades into long-term performance penalties during query execution.

Reworking Bulk Ingestion at the Ingestion Entry Point

To truly address the small-file problem caused by large-scale ingestion, relying on downstream compaction alone is far from sufficient. A closer examination of the entire write pipeline reveals that the root causes are concentrated in several key areas:

Memory constraints force premature flushes. On compute nodes (CNs), memtables are often flushed before they are filled due to limited memory, resulting in relatively small files per flush.
High-latency remote writes in storage–compute separation. Under a storage–compute separation architecture, every flush writes directly to object storage. The combination of high-latency remote I/O and frequent write operations significantly degrades ingestion throughput.
Repeated heavy write work. Each flush triggers the full write pipeline: sorting, encoding, compression, and index construction. Repeating these CPU-intensive steps for small batches wastes substantial compute resources.
Redundant work during compaction . The excessive number of small files must later be read again and merged during compaction. Much of the earlier sorting and encoding effort becomes partially redundant, further amplifying resource waste.

Based on this analysis, StarRocks redesigns the bulk ingestion write path for storage–compute separation scenarios, optimizing it at the entry point of the ingestion pipeline.

1. Write Phase: Spill to Local Disk First

When a memtable is full, data is no longer written directly to object storage. Instead, StarRocks spills intermediate data to local disks on the CN. This approach avoids high-latency object storage writes and prevents repeated execution of heavy operations, such as sorting and encoding, before the data has stabilized. If local disk space becomes constrained, intermediate data can be selectively spilled to object storage (for example, S3) to ensure overall system robustness.

2. Consolidation Phase: Merge First, Then Write to Object Storage

Once the bulk ingestion task completes, StarRocks performs a centralized merge on the temporary spill files. These files are consolidated into well-structured, appropriately sized data files, which are then written to object storage in a single, efficient step.

In summary, the redesigned bulk ingestion pipeline can be described as:

Memory → Local Disk Spill → Centralized Merge → Object Storage

By restructuring the write path in this way, StarRocks tackles the small-file problem at its origin, delivering higher ingestion throughput, better resource utilization, and more stable performance in shared-data architecture deployments.

This optimized bulk ingestion path delivers clear benefits across three key dimensions:

Higher write throughput during ingestion. When a memtable fills up, StarRocks spills intermediate results only to local disk instead of writing directly to backend object storage. By avoiding high-latency remote writes at this stage, the system significantly improves ingestion performance.
Lower CPU and resource overhead. During the spill phase, the system simply persists memtable data to disk without triggering the full write pipeline, such as global sorting, encoding, or index construction. Skipping these expensive operations at intermediate stages reduces unnecessary CPU and memory consumption.
Fewer, larger files with more predictable query performance. All temporary spill files are merged in a single, centralized step before being written to object storage, producing a much smaller number of well-sized data files. This dramatically reduces small-file proliferation and largely eliminates reliance on background compaction. As a result, even if queries are issued immediately after ingestion completes, they can run with stable and predictable performance.

Performance Comparison

To evaluate the real-world impact of the bulk ingestion optimizations described above, we designed two comparative tests on a shared-data architecture cluster:

Single-concurrency scenario: A single ingestion job loading 1 TB of data, comparing ingestion time and post-ingestion query performance before and after the optimization.
High-concurrency scenario: 10 concurrent ingestion jobs, each loading 100 GB (still 1 TB in total), comparing ingestion throughput and query performance after ingestion, before and after the optimization.

Test 1: Single-Concurrency Bulk Ingestion

In this test, we used Broker Load to ingest a 1 TB dataset (approximately 270 million rows) in a single concurrent job.

Before the optimization:

The ingestion phase itself took approximately 2 hours and 15 minutes.
After ingestion was completed, the system spent an additional 34 minutes performing background compaction.

From a user’s perspective, the total time from submitting the ingestion job to the system returning to a stable, query-ready state was approximately 2 hours and 50 minutes.

*************************** 3. row ***************************
JobId: 10409
State: FINISHED
Type: BROKER
SinkRows: 270000000
LoadStartTime: 2024-12-27 10:59:12
LoadFinishTime: 2024-12-27 13:14:04

After the ingestion was completed, the compaction score for the partition was:

AvgCS: 358.06 P50CS: 299.00 MaxCS: 1056.00

When the ingestion finished, the following query was executed immediately:

mysql> select count(*) from duplicate_21_0;
+-----------+
| count(*) |
+-----------+
| 270000000 |
+-----------+
1 row in set (56.25 sec)

After the optimization, the total ingestion time was approximately 2 hours and 42 minutes.

*************************** 2. row ***************************
JobId: 10642
State: FINISHED
Type: BROKER
SinkRows: 270000000
LoadStartTime: 2024-12-27 16:14:08
LoadFinishTime: 2024-12-27 18:56:00

After ingestion was completed, the compaction score was already at the optimal level, requiring no background compaction.

AvgCS: 2.39 P50CS: 2.00 MaxCS: 5.00

Immediately after the ingestion was completed, the query was executed:

mysql> select count(*) from duplicate_21_0;
+-----------+
| count(*) |
+-----------+
| 270000000 |
+-----------+
1 row in set (0.72 sec)

Test 2: High-Concurrency Bulk Ingestion Stress Test

In this test, we ran a high-concurrency ingestion workload on a total dataset of 1 TB. The target table contained 28 partitions, with 256 tablets per partition.

Before the optimization, ingestion was constrained by the CPU and memory resources of the compute nodes. As a result, the workload failed to complete within the 4-hour timeout window and was eventually automatically canceled by the system. The final job state is shown below:

*************************** 10. row ***************************
JobId: 11458
State: CANCELLED
Type: BROKER
Priority: NORMAL
ScanRows: 21905408
LoadStartTime: 2025-01-06 17:11:46
LoadFinishTime: 2025-01-06 21:11:44

After the optimization:

*************************** 20. row ***************************
JobId: 28336
State: FINISHED
Type: BROKER
Priority: NORMAL
ScanRows: 30000000
LoadStartTime: 2025-01-06 20:10:49
LoadFinishTime: 2025-01-06 20:27:59

Under the same conditions, the 10 concurrent ingestion jobs started at 2025-01-06 20:10:49 and all completed by 2025-01-06 20:36:10, for a total runtime of approximately 25 minutes.

Although these jobs did trigger the compaction threshold, the system’s compaction score remained within a healthy and stable range throughout the ingestion and at completion.

vgCS: 10.00 P50CS: 10.00 MaxCS: 10.00

In addition, we can compare several key backend object storage metrics before and after the optimization:

(Key S3 Metrics Before Optimization)

(Key S3 Metrics After Optimization)

(Comparison of Local Disk I/O Utilization Before and After Optimization)

The results clearly show that after this optimization is enabled:

Significantly fewer writes to S3, with much higher throughput . The number of write operations to S3 is drastically reduced, while overall write throughput increases substantially. At the same time, the average object size grows significantly, helping lower storage costs and improving both read and write efficiency.
More effective utilization of local disk I/O during ingestion. The ingestion process is able to fully leverage local disk I/O capacity, leading to a noticeable improvement in overall ingestion performance.

Summary

By optimizing bulk data ingestion at the engine level, StarRocks effectively avoids the proliferation of small files that commonly occurs under resource constraints, especially limited memory, during historical data backfill. This enables users in shared-data architecture environments to achieve higher efficiency and more stable performance with lower infrastructure investment.

Inside StarRocks: Why Joins Are Faster Than You’d Expect

Kate Shao — Wed, 21 Jan 2026 05:18:43 GMT

✍🏼 About The Author:

Seaven He, StarRocks Committer, Engineer at Celerdata

Joins are the hardest part of OLAP. Many systems can’t run them efficiently at scale, so teams denormalize into wide tables instead, 10× their storage, dealing with complex stream processing pipelines, and painfully slow and expensive schema evolution that triggers large backfills.

StarRocks takes the opposite approach: keep data normalized and make joins fast enough to run on the fly. The challenge is the plan. In a distributed system, the join search space is huge, and a good plan can be orders of magnitude faster.

This deep dive explains how StarRocks’ cost-based optimizer makes that possible, in four parts: join fundamentals and optimization challenges, logical join optimizations, join reordering, and distributed join planning. Finally, we examine real-world case studies from NAVER, Demandbase, and Shopee to illustrate how efficient join execution delivers tangible business value.

Join Fundamentals and Optimization Challenges

1.1 Join Types

The diagram above illustrates several common join types:

Cross Join: Produces a Cartesian product between the left and right tables.
Full / Left / Right Outer Join: For rows that do not find a match, outer joins return results with NULL values filled in according to the join semantics—on both tables (full), the left table (left), or the right table (right).
Anti Join: Returns rows that do not have a matching counterpart in the join relationship. Anti-joins typically appear in query plans for NOT IN or NOT EXISTS subqueries.
Semi Join: The opposite of an anti-join, it returns only rows that do have a match in the join relationship, without producing duplicate result rows from the matching side.
Inner Join: Returns the intersection of the left and right tables. Based on the join condition, it may generate one-to-many result rows.

1.2 Challenges in Join Optimization

Join performance optimization generally falls into two areas:

improving the efficiency of join operators on a single node, and
designing a reasonable join plan that minimizes input size and execution cost.

This article focuses on the second aspect. To set the stage, we begin by examining the key challenges in join optimization.

Challenge 1: Multiple Join Implementation Strategies

As shown above, different join algorithms perform very differently depending on the scenario. For example, Sort-Merge Join can be significantly more efficient than Hash Join when operating on already sorted data. However, in distributed databases where data is typically hash-partitioned, Hash Join often outperforms Sort-Merge Join by a wide margin. As a result, the database must choose the most appropriate join strategy based on the specific workload and data characteristics.

Challenge 2: Join Order Selection in Multi-Table Joins

In multi-table join scenarios, executing highly selective joins first can significantly improve overall query performance. However, determining the optimal join order is far from trivial.

As illustrated above, under a left-deep join tree model, the number of possible join orders for N tables is on the order of 2^n-1. Under a bushy join tree model, the number of possible combinations grows even more dramatically, reaching 2^(n-1) * C(n-1). For a database optimizer, the time and cost required to search for the optimal join order therefore increases exponentially, making join ordering one of the most challenging problems in query optimization.

Challenge 3: Difficulty in Estimating Join Effectiveness

Before query execution, it is extremely difficult for the database to accurately predict the real execution behavior of a join. A common assumption is that joining a small table with a large table is more selective than joining two large tables, but this is not always true.

In practice, one-to-many relationships are common, and in more complex queries, joins are often combined with filters, aggregations, and other operators. After data flows through multiple transformations, the optimizer’s ability to accurately estimate join input sizes and selectivity degrades significantly.

Challenge 4: A Single-Node Optimal Plan Is Not Necessarily Optimal in Distributed Systems

Press enter or click to view image in full size

In distributed systems, data often needs to be reshuffled or broadcast across nodes so that the required records can participate in join computation. Distributed joins are no exception.

This introduces a key complication: an execution plan that is optimal in a single-node database may perform poorly in a distributed environment because it ignores data distribution and network transfer costs.

Therefore, when planning join execution strategies in distributed databases, the optimizer must explicitly account for data placement and communication overhead in addition to local execution efficiency.

1.3 SQL Optimization Workflow

In StarRocks, SQL optimization is primarily handled by the query optimizer and is mainly concentrated in the Rewrite and Optimize phases.

1.4 Principles of Join Optimization

At present, StarRocks primarily uses Hash Join as its join algorithm. By default, the right-hand table is used to build the hash table. Based on this design choice, we summarize five key optimization principles:

Different join types have very different performance characteristics. Whenever possible, prefer higher-performance join types and avoid expensive ones. Based on the typical size of join outputs, the rough performance ranking is: Semi Join / Anti Join > Inner Join > Outer Join > Full Outer Join > Cross Join.
When using Hash Join, building the hash table on a smaller input is significantly more efficient than building it on a large table.
In multi-table joins, prioritize joins with high selectivity.
Minimize the amount of data participating in joins whenever possible.
Minimize network overhead introduced by distributed joins.

Join Logical Optimization

This section introduces a set of heuristic rules used by StarRocks to optimize joins at the logical level.

2.1 Type Transformations

The first group of optimizations directly follows the first join optimization principle discussed earlier: transform low-efficiency join types into more efficient ones whenever the semantics allow it.

StarRocks currently applies three major transformation rules.

Rule 1: Converting a Cross Join into an Inner Join

A Cross Join can be rewritten as an Inner Join when it satisfies the following condition:

There exists at least one predicate that expresses a join relationship between the two tables.

For example:

-- Before transformation
SELECT * FROM t1, t2 WHERE t1.v1 = t2.v1

-- After transformation
-- WHERE t1.v1 = t2.v1 is a join predicate
SELECT * FROM t1 INNER JOIN t2 ON t1.v1 = t2.v1;

Rule 2: Converting an Outer Join into an Inner Join

A Left / Right Outer Join can be rewritten as an Inner Join when the following conditions are met:

There exists a predicate referencing the nullable side of the outer join (Right table for a Left Outer Join, or Left table for a Right Outer Join).
The predicate is a strict (null-rejecting) predicate.

Example:

-- Before transformation
SELECT * FROM t1 LEFT OUTER JOIN t2 ON t1.v1 = t2.v1 WHERE t2.v1 > 0;

-- After transformation
-- t2.v1 > 0 is a strict predicate on t2
SELECT * FROM t1 INNER JOIN t2 ON t1.v1 = t2.v1 WHERE t2.v1 > 0;

⚠️ Important note: In an outer join, ON clause predicates participate in null extension, not filtering. Therefore, this rule does not apply to join predicates inside the ON clause:

SELECT * FROM t1 LEFT OUTER JOIN t2 ON t1.v1 = t2.v1 AND t2.v1 > 1;

This query is not semantically equivalent to:

SELECT * FROM t1 INNER JOIN t2 ON t1.v1 = t2.v1 AND t2.v1 > 1;

This introduces the concept of strict (null-rejecting) predicates. In StarRocks, a predicate that filters out NULL values is considered a strict predicate, for example a > 0. Predicates that do not eliminate NULL values are classified as non-strict predicates, such as a IS NULL. Most predicates fall into the strict category; non-strict predicates are primarily those involving IS NULL, IF, CASE WHEN, or certain function-based expressions.

To determine whether a predicate is strict, StarRocks uses a simple yet effective approach: all referenced columns are replaced with NULL, and the expression is then simplified. If the result evaluates to TRUE, it means the WHERE clause does not filter out rows with NULL inputs, and the predicate is therefore non-strict. Conversely, if the result evaluates to FALSE or NULL, the predicate is considered strict.

Rule 3: Converting a Full Outer Join into a Left / Right Outer Join

A Full Outer Join can be rewritten as a Left Outer Join or Right Outer Join when the following condition is satisfied:

There exists a strict predicate that can be bound exclusively to the left or right table.

Example:

-- Before transformation
SELECT * FROM t1 FULL OUTER JOIN t2 ON t1.v1 = t2.v1 WHERE t1.v1 > 0;

-- After transformation
-- t1.v1 > 0 is a strict predicate on the left table
SELECT * FROM t1 LEFT OUTER JOIN t2 ON t1.v1 = t2.v1 WHERE t1.v1 > 0;

2.2 Predicate Pushdown

Predicate pushdown is one of the most important and commonly used join optimization techniques. Its primary purpose is to filter join inputs as early as possible, thereby reducing the amount of data involved in the join and improving overall performance.

For predicates in the WHERE clause, predicate pushdown can be applied—and may enable join type transformations—when the following conditions are satisfied:

The join can be of any type.
The WHERE predicate can be bound to one of the join inputs.

For example:

Select *  
From t1 Left Outer Join t2 On t1.v1 = t2.v1 
        Left Outer Join t3 On t2.v2 = t3.v2 
Where t1.v1 = 1 And t2.v1 = 2 And t3.v2 = 3;

The predicate pushdown process proceeds as follows.

Step 1 :

Push down (t1.v1 = 1 AND t2.v1 = 2) and (t3.v2 = 3) separately. Since the join type transformation rules are satisfied,(t1 LEFT OUTER JOIN t2) LEFT OUTER JOIN t3can be rewritten as (t1 LEFT OUTER JOIN t2) INNER JOIN t3.

Step 2:

Continue pushing down (t1.v1 = 1) and (t2.v1 = 2). At this point,t1 LEFT OUTER JOIN t2 can be further transformed intot1 INNER JOIN t2.

It is important to note that predicate pushdown rules for join predicates in the ON clause differ from those for the WHERE clause. We distinguish between two cases: Inner Joins and other join types.

Case 1: Inner Join

For Inner Joins, pushing down join predicates in the ON clause follows the same rules as WHERE clause predicate pushdown. This has already been discussed above and will not be repeated here.

Case 2: Outer / Semi / Anti Joins

For Outer, Semi, and Anti Joins, predicate pushdown on ON clause join predicates must satisfy the following constraints, and no join type transformation is allowed during the pushdown process:

The join must be a Left or Right Outer / Semi / Anti Join.
The join predicate must be bindable only to the nullable side (the right input for a Left Join, or the left input for a Right Join).

Consider the following example:

Select *  
From t1 Left Outer Join t2 On t1.v1 = t2.v1 And t1.v1 = 1 And t2.v1 = 2 
        Left Outer Join t3 On t2.v2 = t3.v2 And t3.v2 = 3;

The predicate pushdown proceeds as follows.

Step 1:

Push down the join predicate (t3.v2 = 3), which can be bound to the right input of t1 LEFT JOIN t2 LEFT JOIN t3. At this stage, the LEFT OUTER JOIN cannot be converted into an INNER JOIN.

Press enter or click to view image in full size

Step 2:

Push down the join predicate (t2.v1 = 2), which can be bound to the right input oft1 LEFT JOIN t2.

However, the predicate (t1.v1 = 1) is bound to the left input. Pushing it down would filter rows from t1, violating the semantics of a LEFT OUTER JOIN. Therefore, this predicate cannot be pushed down.

Press enter or click to view image in full size

2.3 Predicate Extraction

In the predicate pushdown rules discussed earlier, only predicates with conjunctive semantics can be pushed down. For example, in t1.v1 = 1 AND t2.v1 = 2 AND t3.v2 = 3, each sub-predicate is connected by conjunction, making pushdown straightforward. However, predicates with disjunctive semantics, such ast1.v1 = 1 OR t2.v1 = 2 OR t3.v2 = 3, cannot be pushed down directly.

In real-world queries, disjunctive predicates are quite common. To address this, StarRocks introduces an optimization called predicate extraction (column value derivation). This technique derives conjunctive predicates from disjunctive ones by performing a series of union and intersection operations on column value ranges. The derived conjunctive predicates can then be pushed down to reduce join input size.

For example:

-- Before predicate extraction
SELECT *
FROM t1 JOIN t2 ON t1.v1 = t2.v1
WHERE (t2.v1 = 2 AND t1.v2 = 3)OR (t2.v1 > 5 AND t1.v2 = 4);

Using column value derivation on (t2.v1 = 2 AND t1.v2 = 3) OR (t2.v1 > 5 AND t1.v2 = 4), the optimizer can extract the following predicates:

t2.v1 >= 2
t1.v2 IN (3, 4)

The query can then be rewritten as:

SELECT *
FROM t1 JOIN t2 ON t1.v1 = t2.v1
WHERE (t2.v1 = 2 AND t1.v2 = 3)OR (t2.v1 > 5 AND t1.v2 = 4)AND t2.v1 >= 2
AND t1.v2 IN (3, 4);

It is important to note that the extracted predicates may form a superset of the original predicate ranges. As a result, they cannot safely replace the original predicates and must instead be applied in addition to them.

2.4 Equivalence Derivation

In addition to predicate extraction, another important predicate-level optimization is equivalence derivation. This technique leverages join equality conditions to infer value constraints on one side of the join from predicates applied to the other side.

Specifically, based on the join condition, value ranges on columns from the left table can be used to derive corresponding value ranges on columns from the right table, and vice versa.

For example:

-- Original SQL
SELECT *
FROM t1 JOIN t2 ON t1.v1 = t2.v1
WHERE (t2.v1 = 2 AND t1.v2 = 3)
   OR (t2.v1 > 5 AND t1.v2 = 4);

Using predicate extraction on (t2.v1 = 2 AND t1.v2 = 3) OR (t2.v1 > 5 AND t1.v2 = 4), the optimizer can derive the following predicates:

t2.v1 >= 2
t1.v2 IN (3, 4)

Resulting in:

SELECT *
FROM t1 JOIN t2 ON t1.v1 = t2.v1
WHERE (t2.v1 = 2 AND t1.v2 = 3)
   OR (t2.v1 > 5 AND t1.v2 = 4)
  AND t2.v1 >= 2
  AND t1.v2 IN (3, 4);

Next, using the join predicate (t1.v1 = t2.v1) together with t2.v1 >= 2, equivalence derivation can infer an additional predicate:

t1.v1 >= 2

The query can therefore be further rewritten as:

SELECT *
FROM t1 JOIN t2 ON t1.v1 = t2.v1
WHERE (t2.v1 = 2 AND t1.v2 = 3)
   OR (t2.v1 > 5 AND t1.v2 = 4)
  AND t2.v1 >= 2
  AND t1.v2 IN (3, 4)
  AND t1.v1 >= 2;

Applicability and Constraints

The scope of equivalence derivation is more limited than predicate extraction. Predicate extraction can be applied to arbitrary predicates, whereas equivalence derivation, like predicate pushdown, has different constraints depending on the join type. As before, we distinguish between WHERE predicates and ON clause join predicates.

For WHERE predicates:

There are almost no restrictions. Predicates can be derived from the left table to the right table and vice versa.

For ON clause join predicates:

For Inner Joins, the rules are the same as for WHERE predicates—no additional constraints apply.
For join types other than Inner Join, only Semi Joins and Outer Joins are supported, and derivation is one-directional only, opposite to the join direction:
For a Left Outer Join, predicates can be derived from the left table to the right table.
For a Right Outer Join, predicates can be derived from the right table to the left table.

Why Is Equivalence Derivation One-Directional for Outer / Semi Joins?

The reason is straightforward. Consider a Left Outer Join. As discussed in predicate pushdown rules, only predicates on the right table can be pushed down; predicates on the left table cannot, as doing so would violate the semantics of a left outer join.

For the same reason, predicates derived from the right table and applied to the left table must also respect this constraint. In practice, such derived predicates on the preserved side do not help filter data early and instead introduce additional evaluation overhead. Therefore, equivalence derivation for Outer and Semi Joins is intentionally restricted to a single direction.

Implementation Details

StarRocks implements equivalence derivation by maintaining two internal maps:

One map tracks column-to-column equivalence relationships.
The other map tracks column-to-value or column-to-expression equivalences.

By performing lookups and inference across these two maps, the optimizer derives additional equivalent predicates. The overall mechanism is illustrated below:

2.5 Limit Pushdown

In addition to predicates, LIMIT clauses can also be pushed down through joins. When a query involves an Outer Join or a Cross Join, the LIMIT can be pushed down to child operators whose output row count is guaranteed to be stable.

For example, in a Left Outer Join, the output row count is at least the same as that of the left input. Therefore, the LIMIT can be pushed down to the left table (and symmetrically for a Right Outer Join).

-- Before pushdown
SELECT *
FROM t1 LEFT OUTER JOIN t2 ON t1.v1 = t2.v1
LIMIT 100;

-- After pushdown
SELECT *
FROM (SELECT * FROM t1 LIMIT 100) t
LEFT OUTER JOIN t2 ON t.v1 = t2.v1
LIMIT 100;

Special Cases: Cross Join and Full Outer Join

A Cross Join produces a Cartesian product, with output cardinality equal torows(left) × rows(right). A Full Outer Join produces at leastrows(left) + rows(right).

For these join types, a LIMIT can be pushed down to both inputs independently:

-- Before pushdown
SELECT *
FROM t1 JOIN t2
LIMIT 100;

-- After pushdown
SELECT *
FROM (SELECT * FROM t1 LIMIT 100) x1
JOIN (SELECT * FROM t2 LIMIT 100) 
LIMIT 100;

Join Reordering

Join reordering is used to determine the execution order of multi-table joins. The optimizer aims to execute high-selectivity joins as early as possible, thereby reducing the size of intermediate results and improving overall query performance.

In StarRocks, join reordering primarily operates on continuous sequences of Inner Joins or Cross Joins. As illustrated below, StarRocks groups a sequence of consecutive Inner / Cross Joins into a Multi Join Node. A Multi Join Node is the basic unit for join reordering: if a query plan contains multiple such nodes, StarRocks performs join reordering independently for each one.

There are many join reordering algorithms in the industry, often based on different optimization models, including:

Heuristic-based approaches: Rely on predefined rules, such as those used in MemSQL, where join order is determined around dimension tables and fact tables.
Left-Deep Trees: Restrict plans to left-deep trees, significantly reducing the search space, though the resulting plan is not always optimal.
Bushy Trees: Allow fully bushy join trees, resulting in a much larger search space that includes the optimal plan. Common reordering algorithms under this model include:
Exhaustive search (based on commutativity and associativity)
Greedy algorithms
Simulated annealing
Dynamic programming (e.g., DPsize, DPsub, DPccp)
Genetic algorithms (e.g., Greenplum)
……

StarRocks currently implements several join reordering strategies, including Left-Deep, Exhaustive, Greedy, and DPsub. In the following sections, we focus on the implementation details of Exhaustive and Greedy join reordering in StarRocks.

3.1 Exhaustive

The exhaustive join reordering algorithm is based on systematically enumerating all possible join orders. In practice, this is achieved through two fundamental rules, which together cover nearly the entire space of join permutations.

Rule 1: Join Commutativity

A join between two relations can be reordered by swapping its inputs:A JOIN B → B JOIN A

During this transformation, the join type must be adjusted accordingly. For example, a LEFT OUTER JOIN becomes a RIGHT OUTER JOIN after swapping the join operands.

Rule 2: Join Associativity

Join associativity allows the join order among three relations to be rearranged:(A JOIN B) JOIN C → A JOIN (B JOIN C)

In StarRocks, associativity is handled differently depending on the join type. Specifically, StarRocks distinguishes between:

Associativity for Inner / Cross Joins
Associativity for Semi Joins

3.2 Greedy

For its greedy join reordering strategy, StarRocks primarily draws inspiration from multi-sequence greedy algorithms, with a small but important enhancement: at each iteration level, instead of keeping only a single best result, StarRocks retains the top 10 candidate plans (which may not be globally optimal). These candidates are then carried forward into the next iteration, ultimately producing 10 greedy-optimized plans.

Due to the inherent limitations of greedy algorithms, this approach does not guarantee a globally optimal plan. However, by preserving multiple high-quality candidates at each step, it significantly increases the likelihood of finding a near-optimal or optimal solution.

Press enter or click to view image in full size

3.3 Cost Model

StarRocks uses these join reordering algorithms to generate N candidate plans. It then evaluates them with a cost model that estimates the cost of each join. The overall cost is computed as: Join Cost = CPU × (Row(L) + Row(R)) + Memory × Row(R)

Here, Row(L) and Row(R) are the estimated output row counts of the join’s left and right children, respectively. This formula primarily accounts for the CPU cost of processing both inputs, as well as the memory cost of building the hash table on the right side of a hash join. The figure below shows how StarRocks estimates join output row counts in more detail.

Because different join reordering algorithms explore search spaces of varying sizes and have different time complexities, StarRocks benchmarks their execution time and complexity characteristics, as shown below.

Based on the observed execution costs, StarRocks applies practical limits to how different join reordering algorithms are used:

For joins involving up to 4 tables, StarRocks uses the exhaustive algorithm.
For joins with 4–10 tables, StarRocks generates:
1 plan using the left-deep strategy,
10 plans using the greedy algorithm,
1 plan using dynamic programming.

On top of these, StarRocks further explores additional plans using join commutativity.

For joins with more than 10 tables, StarRocks relies only on the greedy and left-deep strategies, producing a total of 11 candidate plans as the basis for reordering.
When statistics are unavailable, cost-based greedy and dynamic programming approaches become unreliable. In this case, StarRocks falls back to using a single left-deep plan as the basis for join reordering.

Distributed Join Planning

After covering the logical optimizations involved in join queries, we now turn to join execution in a distributed environment, focusing on how StarRocks optimizes distributed join planning as a distributed database.

4.1 MPP Parallel Execution

StarRocks is built on an MPP (Massively Parallel Processing) execution framework. The overall architecture is illustrated below. Using a simple join query as an example, the execution of A JOIN B in StarRocks typically proceeds as follows:

Data from tables A and B is read in parallel from different nodes, based on their respective data distributions.
According to the join predicate, data from A and B is reshuffled so that matching rows are sent to the same set of nodes.
The join is executed locally on each node, and the partial results are produced.

As shown, query execution usually involves multiple sets of machines: the nodes reading table A, the nodes reading table B, and the nodes performing the join are not necessarily the same. As a result, execution inevitably involves network transfers and data exchanges.

These network operations introduce significant overhead. Therefore, a key goal in optimizing distributed join execution in StarRocks is to minimize network cost, while more intelligently partitioning and distributing the query plan to fully leverage the benefits of parallel execution.

4.2 Distributed Join Optimization

We begin by introducing the distributed execution plans that StarRocks can generate. Using a simple join query as an example:

Select * From A Join B on A.a = B.b

In practice, StarRocks can generate five basic types of distributed join plans:

Shuffle Join Data from both tables A and B is shuffled based on the join key so that matching rows are sent to the same set of nodes, where the join is then executed.
Broadcast Join The entire table B is broadcast to all nodes that hold table A, and the join is performed locally on those nodes. Compared to a shuffle join, this avoids shuffling table A, but requires broadcasting all of table B. This strategy is suitable when B is a small table.
Bucket Shuffle Join An optimization over broadcast join. Instead of broadcasting table B to all nodes, B is shuffled according to A’s data distribution and sent only to the corresponding nodes that hold matching buckets of A. Globally, the shuffled data from B exists only once, significantly reducing network traffic compared to broadcast join. This strategy has an important constraint: the join key must be consistent with A’s distribution key.
Colocate Join When tables A and B are created within the same colocate group, their data distributions are guaranteed to be identical. If the join key matches the distribution key, StarRocks can execute the join directly on the local nodes holding A and B, without any data shuffle.
Replicate Join An experimental feature in StarRocks. If every node holding table A also contains a full copy of table B, the join can be executed locally. This approach has very strict requirements — essentially requiring the replication factor of table B to match the total number of nodes in the cluster — making it impractical in most real-world scenarios.

4.3 Exploring Distributed Join Plans

StarRocks derives distributed join plans through distribution property inference. Using a shuffle join as an example:SELECT * FROM A JOIN B ON A.a = B.b, the join operator propagates shuffle requirements top-down to tables A and B. If a scan node cannot satisfy the required distribution, StarRocks inserts an Enforce operator to introduce a shuffle. In the final execution plan, this shuffle is translated into an Exchange node responsible for network data transfer.

Other distributed join strategies are derived in the same way: the join operator requests different distribution properties from its input operators, and the optimizer generates the corresponding distributed execution plans accordingly.

4.4 Complex Distributed Joins

In real-world workloads, user queries are far more complex than a simple A JOIN B. They often involve three or more tables. For such queries, StarRocks generates a richer set of distributed execution plans, all derived from the same fundamental join strategies described earlier.

For example:

Select * From A Join B on A.a = B.b Join C on A.a = C.c

Using combinations of Shuffle Join and Broadcast Join, StarRocks can derive multiple distributed plans, as illustrated below.

If Colocate Join and Bucket Shuffle Join are also considered, even more execution plans become possible:

Despite their increased complexity, the underlying derivation logic remains the same. Distribution properties are propagated downward through the plan tree, allowing the optimizer to infer different combinations of distributed join strategies.

4.5 Global Runtime Filters

Beyond exploring distributed execution plans, StarRocks further optimizes join performance by leveraging the execution characteristics of join operators to build Global Runtime Filters.

The execution flow of a Hash Join in StarRocks is as follows:

Retrieve the complete data set from the right table.
Build a hash table from the right table.
Fetch data from the left table.
Probe the hash table to evaluate join conditions.
Produce the join results.

Global Runtime Filters are applied between Step 2 and Step 3. After constructing the hash table on the right side, StarRocks derives runtime filter predicates from the observed data and pushes these filters down to the scan nodes of the left table before left-side data is read. This allows the left table to filter out irrelevant rows early, significantly reducing join input size.

At present, Global Runtime Filters in StarRocks support the following filtering techniques: Min/Max filters, IN predicates, and Bloom filters. The diagram below illustrates how these filters work in practice.

Summary

This article has explored StarRocks’ practical experience and ongoing work in join query optimization. All of the techniques discussed are closely aligned with the core optimization principles outlined throughout the article. When optimizing SQL queries in practice, users can also apply the following guidelines together with the features provided by StarRocks to achieve better performance:

Join operators vary significantly in performance. Prefer high-performance join types whenever possible and avoid expensive ones. Based on typical join output sizes, the rough performance ranking is: Semi Join / Anti Join > Inner Join > Outer Join > Full Outer Join > Cross Join.
For hash joins, building the hash table on a smaller input is far more efficient than building it on a large table.
In multi-table joins, execute highly selective joins first to substantially reduce the cost of subsequent joins.
Minimize the amount of data participating in joins through early filtering and pruning.
Reduce network overhead in distributed joins as much as possible to fully benefit from parallel execution.

Case Studies

Demandbase

By leveraging StarRocks’ On-the-Fly JOIN capabilities, Demandbase successfully replaced its existing ClickHouse clusters, optimizing performance while significantly reducing costs across multiple areas.

Read the case study: Demandbase Ditches Denormalization By Switching off ClickHouse

Naver

NAVER modernized its data infrastructure with StarRocks by enabling scalable, real-time analytics over multi-table joins without denormalization. The case study highlights the critical role of efficient, on-the-fly join execution in supporting production-scale analytical workloads.

Read the case study: How JOIN Changed How We Approach Data Infra At NAVER

Shopee

Data Go is a no-code query platform where Shopee business users build queries from multiple tables. Presto struggled with complex join performance and high resource usage. When Shopee switched to StarRocks for multi-table joins, they observed 3×–10× performance improvements and a ~60% reduction in CPU usage compared with Presto on external Hive data.

Read the case study: How Shopee 3xed Their Query Performance With StarRocks