Component reference

StarRocks + ClickHouse — engine specialization

Two engines reading the same Iceberg data, each pinned to the workload it measurably wins on. ClickHouse for scheduled queries (dashboards, alerts, sub-second materialized views). StarRocks for ad-hoc investigations (cost-based optimizer, multi-table joins, flexible schema). The SDW join bench (single host, Tier B) confirms the role assignments point the right way, though the gaps are small at SOC scale, so the pairing is justified by isolation, right-sizing, and operating cost more than by raw speed. The dual-engine pattern is MOAr Principle #5 — query engine specialization.

The pipeline

1. Store

   Iceberg on S3

   Single source of truth; both engines read the same data

2. →

3. Scheduled

   ClickHouse cluster

   Materialized views; <500 ms dashboard refresh; 100K+ events/sec ingest

4. →

5. Ad-hoc

   StarRocks cluster

   Cost-based optimizer; multi-table joins; flexible schema evolution

6. →

7. Notebook

   DuckDB (optional)

   Embedded analytics on the same Iceberg tables

8. →

9. Serve

   Grafana + analyst UIs

   Dashboards routed to CH; investigations routed to SR

What composes, what’s brittle

• Why ClickHouse for scheduled. Incremental materialized views on insert; columnar scans tuned for time-series.
• Why StarRocks for ad-hoc. CBO + hash/merge/broadcast join strategies; CTEs and BETWEEN time joins.
• Same Iceberg data. No copy-out; 20+ engines support the spec, so detection content stays portable.
• Where ClickHouse struggles. Multi-table joins, now lab-measured: StarRocks won 4 of 5 TPC-H-derived joins and ran the heaviest 6-table join 2.7–2.8× faster than both ClickHouse arms, though every SOC-suite join finished under 1.5 s on every engine (single host, Tier B). The vendor TB-scale claim (30–120 s vs. 5–30 s) is a different regime the bench neither confirms nor refutes.
• Where StarRocks struggles. Aggregation shapes: ClickHouse took q18, the most aggregation-shaped join (1.186 s vs. 1.893 s), and StarRocks won no single-table shape on the earlier 100M-row workload matrix, where the ClickHouse full-scan count ran 10.5 ms to StarRocks' 48.2 ms (both single host, Tier B). The ecosystem is also smaller than ClickHouse's.
• What's brittle. The join specialization is now lab-measured rather than vendor-claimed, but it is small at SOC scale, and the sharpest finding was operational: ClickHouse's own native table was the bench's only DNF (q5, >300 s) while the same engine over Iceberg answered in 1.35 s (single host, Tier B; mechanism instrumented 2026-06-10: stats-blind greedy join reordering on the native path built a ~1.2B-row intermediate, and with reordering disabled the same table answers in 5.3 s). Choose on catalog maturity, concurrency behavior, and operating cost; pilot on real OCSF workload before committing.

Sources: ClickHouse documentation + Netflix/Huntress production references · StarRocks documentation and vendor benchmarks (starrocks.io) — TB-scale claims still without independent validation · SDW engine-join-specialization bench, scored June 2026 (first-party lab measurement, single host, Tier B — a different scale regime) · ClickBench (benchmark.clickhouse.com)