Apache Doris vs StarRocks: an architecture fit assessment

1. Executive summary

These two are close cousins — StarRocks was forked from Doris in 2020 and the two have diverged substantially since, most of all in the query engine and the lakehouse story (StarRocks Engineering, comparison). For the serving workload above, both clear the bar. They separate on emphasis: StarRocks leans into join-heavy BI and lakehouse-native querying; Doris leans into real-time upsert serving and cost efficiency on commodity hardware.

Verdict: Adopt (for high-concurrency BI + lakehouse acceleration)
Best fit: join-heavy BI on normalized/star schemas; Iceberg query
          acceleration with MV query rewrite; a Trino replacement for
          interactive lakehouse SQL.
Main risks: self-managed operational load; enterprise governance
          (row/column masking, lineage) leans on external Apache Ranger;
          managed path concentrates on one vendor (CelerData).
Required mitigations: platform-team ownership or CelerData BYOC; Ranger
          integration for masking/RLS; materialized-view maintenance
          discipline; capacity plan for shared-data cache.
Recommended next step: 4-week POC + head-to-head benchmark vs the
          incumbent warehouse and/or Trino.

Verdict: Adopt (for real-time upsert serving) / Pilot (lakehouse-first)
Best fit: mutable real-time tables and CDC mirrors (Merge-on-Write);
          cost-sensitive self-managed OLAP; unified point-lookup +
          aggregation serving behind a MySQL-protocol endpoint.
Main risks: governance depth trails StarRocks/Snowflake; the 3.0
          compute-storage-decoupled mode is newer in production; DR
          tooling for decoupled mode still maturing; self-managed ops.
Required mitigations: external governance layer; decoupled-mode DR
          runbook + tested restore; dedicated platform ownership;
          version discipline (stay on a stable 3.0.x line).
Recommended next step: 4-week POC focused on CDC upsert throughput,
          freshness SLA, and decoupled-mode failover.

Top strengths (both): interactive latency at high concurrency from vectorized MPP execution; genuine real-time upserts (StarRocks Primary Key / Doris Merge-on-Write) that most OLAP engines fake badly; open-source economics with a compute-storage-decoupled mode that cuts storage cost dramatically on object storage. Top risks (both): you own the cluster unless you buy the managed edition; enterprise governance is thinner than Snowflake and mostly delegated to Apache Ranger; the newest decoupled/shared-data modes are still accruing production mileage for DR.

2. Platform positioning

Both are MPP, columnar, vectorized analytical databases with a two-tier process model — a frontend (FE) that holds metadata and plans queries, and backends (BE) that store and execute. Both speak the MySQL wire protocol, both support the same family of table models (Duplicate / Aggregate / Unique / Primary-Key), and both now offer a decoupled storage-compute mode over object storage. I've written the internals up in depth already — see the deeper-reading box at the end. The positioning differences that matter for this decision:

Against the comparators: Snowflake is the elastic, fully-managed, governance-rich warehouse of record — unmatched on ops, elasticity, and security, weakest on always-on serving cost and continuous low-latency upserts. ClickHouse is the fastest single-table scan/aggregation engine and extremely resource-efficient, but weaker on joins, upserts/CDC, and lakehouse federation. Doris and StarRocks sit between: warehouse-grade SQL and joins at ClickHouse-adjacent latency, with real upserts — at open-source economics.

3. Radar criteria — the reasoning

Query performance

StarRocks' from-scratch CBO + vectorized engine is the class leader for join-heavy workloads — public comparisons put it well ahead of ClickHouse on JOINs and 3–5× Trino on TPC-H (JusDB, 2026); its MV query rewrite is a real latency lever. StarRocks 4.7. Doris is very close — vectorized, CBO, strong point-lookups via MoW — but its optimizer is marginally behind on the hardest join plans. Doris 4.4. ClickHouse wins raw scan/aggregation but loses on joins (4.6); Snowflake is excellent but tuned for warehouse concurrency, not sub-second serving (4.2).

Real-time ingestion

Both offer Stream Load, Routine Load (native Kafka consumption), Flink connectors with exactly-once into the upsert model, and CDC mirrors. This is the shared crown jewel — genuine mutable real-time tables, not eventual-merge hacks. Both 4.3. ClickHouse ingests at very high throughput but upserts/deletes are awkward (ReplacingMergeTree is eventual) — 4.0. Snowflake's Snowpipe Streaming has closed the gap but the mindset is still micro-batch — 3.6.

Lakehouse fit

StarRocks is the strongest OSS OLAP engine on the lake right now: external catalogs across Iceberg/Hudi/Delta/Hive/Paimon, MV rewrite over Iceberg, Iceberg writes via position-delete files, global dictionaries for external Parquet/ORC (3.5), and Polaris integration — 4.4. Doris' Multi-Catalog federation is solid and query-in-place works well, but the acceleration/MV-over-lake story is less mature — 4.0. Snowflake's Iceberg + Open Catalog is strong but historically proprietary-storage-first — 4.1. ClickHouse reads Iceberg/Delta via table functions but isn't lakehouse-native — 3.5.

SQL & data modeling

Snowflake sets the bar — deepest ANSI coverage, VARIANT semi-structured, first-class dbt — 4.7. StarRocks (4.1) and Doris (4.0) both cover window functions, complex joins, the four table models, and materialized views, with dbt adapters; both carry MySQL-dialect quirks and a few advanced-function gaps. ClickHouse is powerful but idiosyncratic, with weaker join ergonomics — 3.8.

Cloud elasticity & scalability

Snowflake is the reference for elastic multi-cluster compute and per-second autoscale — 4.6. StarRocks shared-data (3.0+) with elastic Compute Nodes and a K8s operator earns 3.9; Doris' decoupled mode with multi-cluster workload isolation earns 3.8 (newer in production). ClickHouse Cloud's SharedMergeTree separation is strong; OSS scaling is more manual — 3.9.

Reliability / HA / DR

Snowflake — managed, replicated, Time Travel, cross-region — 4.8. StarRocks earns 3.8: Raft-based FE metadata HA, replicas, and — importantly — 3.5 added cluster snapshots for shared-data, closing a real backup/DR gap (3.5 notes). Doris has FE HA, replicas, and backup/restore, but DR tooling for the decoupled mode is still maturing — 3.6. ClickHouse: ReplicatedMergeTree + Keeper — 3.7.

Governance & security

Snowflake dominates — mature RBAC, dynamic masking, row access policies, SSO/SCIM, audit, lineage — 4.8. StarRocks reaches 3.7 on the strength of native RBAC plus Apache Ranger integration for row filters and column masking (docs). Doris has RBAC and workload groups but thinner native masking/RLS and less catalog/lineage integration — 3.3. ClickHouse has RBAC + row policies but is less enterprise-integrated — 3.3.

Operations & observability

Snowflake's near-zero-ops model and account-usage views lead — 4.6. Both open engines require you to run and tune clusters — compaction, tablet balance, upgrades, and (for the new modes) cache sizing. StarRocks 3.6, Doris 3.5; the managed editions (CelerData / VeloDB) materially raise these. ClickHouse is powerful but operationally demanding (Keeper, merges, sharding) — 3.5.

Ecosystem integration

Snowflake's partner/marketplace breadth is unmatched — 4.6. ClickHouse's community and driver ecosystem is huge — 4.0. Doris and StarRocks both ride the MySQL protocol (so most BI tools connect), have dbt adapters, and Flink/Kafka/Spark connectors; both are growing fast — both 3.8.

TCO & cost efficiency

The open engines win decisively for always-on serving. Doris' decoupled mode advertises up to 90% storage cost reduction vs three-replica coupled mode (Doris blog); StarRocks shared-data is comparable. Doris 4.4, StarRocks 4.3, ClickHouse 4.4 (famously resource-efficient). Snowflake is the most expensive for continuous serving as credits accrue — 3.2. Caveat: OSS "free" hides real headcount cost for platform ownership — factor a dedicated owner into TCO.

4. Radar scorecard

Reference scores — Snowflake: 4.2 / 3.6 / 4.1 / 4.7 / 4.6 / 4.8 / 4.8 / 4.6 / 4.6 / 3.2. ClickHouse: 4.6 / 4.0 / 3.5 / 3.8 / 3.9 / 3.7 / 3.3 / 3.5 / 4.0 / 4.4 (same axis order as the table).

5. The radar

radar-beta
  title Analytical Platform Architecture Radar
  axis Perf["Query Perf"], RT["Real-Time"], Lake["Lakehouse"], SQL["SQL & Modeling"], Cloud["Elasticity"], HA["HA / DR"], Gov["Governance"], Ops["Ops"], Eco["Ecosystem"], Cost["Cost Eff."]
  curve Doris["Apache Doris"]{ Perf: 4.4, RT: 4.3, Lake: 4.0, SQL: 4.0, Cloud: 3.8, HA: 3.6, Gov: 3.3, Ops: 3.5, Eco: 3.8, Cost: 4.4 }
  curve StarRocks["StarRocks"]{ Perf: 4.7, RT: 4.3, Lake: 4.4, SQL: 4.1, Cloud: 3.9, HA: 3.8, Gov: 3.7, Ops: 3.6, Eco: 3.8, Cost: 4.3 }
  curve Snowflake["Snowflake"]{ Perf: 4.2, RT: 3.6, Lake: 4.1, SQL: 4.7, Cloud: 4.6, HA: 4.8, Gov: 4.8, Ops: 4.6, Eco: 4.6, Cost: 3.2 }
  curve ClickHouse["ClickHouse"]{ Perf: 4.6, RT: 4.0, Lake: 3.5, SQL: 3.8, Cloud: 3.9, HA: 3.7, Gov: 3.3, Ops: 3.5, Eco: 4.0, Cost: 4.4 }
  max 5
  min 0
  ticks 5
  graticule polygon
          

Interactive version — click a platform in the legend to toggle it on or off and compare shapes directly:

6. Workload-specific analysis

7. Reference architecture

The target-state serving platform is the same shape for either engine — sources feed both a streaming path (Kafka/CDC → the upsert table model) and a batch/lake path (object storage + Iceberg via the catalog), with governance, data quality, and observability crosscutting. The engine sits in the serving tier behind BI, APIs, and the reverse-ETL/feature consumers.

flowchart LR
  Sources[Source Systems] --> CDC[Debezium / CDC]
  Sources --> Batch[Batch Files / APIs]
  CDC --> Kafka[Kafka]
  Kafka --> Flink[Flink exactly-once]
  Flink --> Engine[(Doris / StarRocks
Primary-Key / MoW)]
  Batch --> Lake[Object Storage]
  Lake --> Iceberg[Iceberg + Catalog]
  Iceberg --> Engine
  Engine --> MV[Materialized Views]
  MV --> BI[BI Dashboards]
  Engine --> API[Serving APIs]
  Engine --> Feat[Feature / Reverse-ETL]
  IAM[SSO / RBAC / Ranger] -.governs.-> Engine
  DQ[Data Quality] -.checks.-> Engine
  Obs[Metrics / Query Profiles] -.observes.-> Engine
          

A StarRocks-flavored acceleration pattern that Doris does not match as cleanly today — an async materialized view over an Iceberg external table, which the optimizer then transparently rewrites queries to hit:

-- StarRocks: MV over lakehouse data, refreshed async, used via query rewrite
CREATE MATERIALIZED VIEW mv_orders_daily
DISTRIBUTED BY HASH(region) BUCKETS 12
REFRESH ASYNC EVERY (INTERVAL 5 MINUTE)
PROPERTIES ("query_rewrite" = "true")
AS
SELECT region, order_date, count(*) orders, sum(amount) revenue
FROM iceberg_catalog.sales.orders
GROUP BY region, order_date;

8. POC & benchmark plan (4 weeks)

Run both engines through the same gauntlet on your data, not TPC-H alone. Decide on measured behavior under your concurrency and freshness targets.

• Week 1 — architecture & setup: stand up each cluster (decoupled/shared-data mode on object storage), model the two hottest serving tables (one append-only, one upsert/CDC), wire SSO + a Ranger baseline (SR), enable Prometheus + query profiling.
• Week 2 — load & query: batch backfill from the lake; continuous Kafka Routine Load + Flink CDC into the upsert table; run the real dashboard query set and a synthetic concurrency ramp; build MVs and confirm query rewrite.
• Week 3 — enterprise readiness: kill an FE and a BE/CN and measure recovery; take a snapshot and restore (SR 3.5 shared-data snapshots / Doris backup); test RLS + column masking; prove workload-group isolation (a heavy tenant must not starve others); track cost.
• Week 4 — evaluate: update this scorecard with measured numbers, write the ADR, estimate migration effort, and commit to Adopt / Pilot / Defer per engine.

9. Final recommendation

Recommendation
  StarRocks : Adopt  — high-concurrency BI + Iceberg lakehouse acceleration
  Doris     : Adopt  — real-time upsert serving; Pilot if lakehouse-first

Choose StarRocks if...
  - joins over star/normalized schemas dominate the query mix
  - you want to accelerate or partially replace Trino on Iceberg
  - Ranger-based RLS/column masking satisfies governance

Choose Doris if...
  - high-churn CDC upserts / mutable tables are the core workload
  - cost efficiency on commodity/self-managed infra is paramount
  - a simpler single-engine MySQL-protocol serving layer is the goal

Not recommended (either) for...
  - system-of-record governed warehouse with deep lineage/masking
  - a team with no capacity to own cluster operations (buy managed)
  - spiky ad-hoc exploration better served by an elastic warehouse

Key risks → mitigations
  - Ops burden          -> CelerData / VeloDB, or a funded platform team
  - Governance depth    -> Apache Ranger + upstream masking; keep PII off hot tier
  - New decoupled modes -> tested DR/restore runbook before production cutover

Decision conditions
  - Adopt if the POC hits P95 < 800 ms at target concurrency AND
    CDC freshness < 10 s AND restore is proven.
  - Defer if governance/lineage requirements exceed Ranger's reach.
  - Reassess in 2 quarters as decoupled-mode DR and MV rewrite mature.

Scores are my own architect-level judgment for a specific use case, calibrated to mid-2026 releases — not a vendor ranking or an absolute verdict. Re-score against your own POC numbers before you commit. Sources are linked inline throughout.