StarRocks and Apache Doris are open-source MPP (massively parallel processing) analytical databases descended from the same lineage as Apache Doris (originally Baidu’s Palo). Doris graduated to an Apache top-level project; StarRocks (StarRocks, Inc., backed by CelerData) forked and went its own direction in 2020. Both are positioned as low-latency, high-concurrency alternatives to Trino for interactive BI on a lakehouse, with native readers for Iceberg, Hudi, Delta, and Paimon.
StarRocks and Apache Doris are MPP analytical databases built for low-latency, high-concurrency SQL. Both trace back to Baidu's Palo project: Doris was donated to the Apache Software Foundation, and StarRocks began as a fork in 2020 that rewrote much of the execution engine. They share a simple two-role architecture, speak the MySQL wire protocol, and combine a native columnar storage engine with connectors that query open lake formats in place. In a modern stack they usually sit at the serving layer: Spark or Flink build tables in a lake, and StarRocks or Doris answers dashboard and customer-facing queries with sub-second latency.
Frontend nodes handle SQL parsing, cost-based optimisation, metadata and cluster management; several FEs replicate metadata for high availability. Backend nodes store tablets (horizontal shards of a table) and execute plan fragments using vectorised, pipelined operators. Tables are distributed by hash on a bucket key and can be range- or list-partitioned, usually by date. Both systems offer table models for different write patterns: duplicate (append-only detail), aggregate (pre-aggregated on load), unique or primary key (upserts). Newer versions can separate storage from compute so that data lives in object storage while compute nodes cache hot data locally.
Materialized views precompute joins and aggregates. Synchronous (rollup-style) views are maintained on every load of a single table; asynchronous views can span multiple tables, including external lake tables, and refresh on a schedule or on change. The optimizer rewrites eligible queries to read a view, so dashboards gain speed without changing their SQL. This is a major reason these engines can serve thousands of concurrent queries on modest hardware.
-- Native table: partitioned by day, hash-distributed for parallelism
CREATE TABLE events (
event_date DATE,
user_id BIGINT,
country VARCHAR(8),
revenue DECIMAL(12,2)
)
DUPLICATE KEY(event_date, user_id)
PARTITION BY RANGE(event_date) (
PARTITION p2026_09 VALUES LESS THAN ("2026-10-01"),
PARTITION p2026_10 VALUES LESS THAN ("2026-11-01")
)
DISTRIBUTED BY HASH(user_id) BUCKETS 16;
-- Async materialized view for a dashboard
CREATE MATERIALIZED VIEW daily_country_rev
REFRESH ASYNC EVERY (INTERVAL 5 MINUTE)
AS SELECT event_date, country, SUM(revenue) AS rev, COUNT(DISTINCT user_id) AS users
FROM events GROUP BY event_date, country;
-- Query the base table; the optimizer may answer it from the MV
SELECT country, SUM(revenue) FROM events
WHERE event_date >= '2026-09-01' GROUP BY country ORDER BY 2 DESC LIMIT 10;
-- Query an Iceberg table in place through an external catalog
SELECT COUNT(*) FROM iceberg_catalog.analytics.page_views WHERE dt = '2026-09-30';
# any MySQL client works (FE query port is 9030 by default)
mysql -h fe-host -P 9030 -u root -e "SHOW BACKENDS\G"
The DDL syntax shown is common to both engines with minor differences; check the documentation of the version you run, particularly for external catalog and MV options.
| Engine | Best at | Trade-off |
|---|---|---|
| StarRocks / Doris | Sub-second BI and customer-facing analytics at high concurrency, lake acceleration | Cluster to operate; native storage adds load pipelines |
| Trino / Presto | Federated SQL across many sources, ad-hoc exploration | No native storage; higher latency under concurrency |
| ClickHouse | Very fast single-table scans and log analytics | Joins and updates are weaker; different SQL dialect |
| Snowflake / BigQuery | Fully managed warehouse | Cost at high query volume; less control |