Arc on ClickBench: StarRocks. This One Depends on the Machine.

We've been running Arc against every major analytical database on ClickBench. First ClickHouse, then TimescaleDB, InfluxDB/DataFusion, Elasticsearch, and CrateDB.

StarRocks is the first one where the answer isn't one-sided.

On high-end hardware, StarRocks leads. On the more commodity c6a.4xlarge, Arc leads. If you're looking for a benchmark post where one system wins everywhere, this isn't it.

What StarRocks Is

StarRocks is a distributed OLAP database built for real-time analytics. In its own documentation, StarRocks positions itself as an MPP analytical database for sub-second queries at scale, with a vectorized execution engine and columnar storage. That's much closer to Arc's intended workload than Elasticsearch or CrateDB.

That matters. When we compared Arc against search engines or PostgreSQL-based time-series systems, the architectural mismatch was obvious. StarRocks is different. It's built for analytical SQL, dashboards, aggregations, and high-concurrency reporting. You'd expect the gap to narrow.

It does.

ClickBench: Same Benchmark, Split Result

ClickBench is the standard public benchmark for analytical databases: 99.9M rows, 43 analytical queries, open source, fully reproducible. Lower relative time is better.

One important methodology note: Arc already runs true cold runs. Before every query, the service is restarted and the OS page cache is dropped. StarRocks is still listed in https://github.com/ClickHouse/ClickBench/issues/793, the tracking issue for migrating submissions from lukewarm to true cold runs. That does not mean Arc automatically wins after the migration. It does mean StarRocks's published cold numbers may worsen once the benchmark switches it to true cold methodology. Arc's won't move.

With that caveat out of the way, here's the actual result: this one depends on the machine.

Combined Score

On c8g.metal-48xl, StarRocks is about 1.18x faster on combined score.

On c6a.4xlarge, Arc is about 1.22x faster.

That may not sound dramatic compared to some of the earlier posts in this series. That's the point. StarRocks is a real OLAP competitor, and the numbers look like it.

Cold Run

On c8g.metal-48xl, StarRocks is only about 1.02x faster on cold runs. That's effectively a near tie.

On c6a.4xlarge, Arc is about 1.13x faster on cold runs.

This is also where the true-cold caveat matters most. StarRocks is still on the migration list for issue #793, so these cold numbers should be read with that in mind.

Hot Run

This is where the split gets sharper.

On c8g.metal-48xl, StarRocks is about 2.38x faster on hot runs.

On c6a.4xlarge, Arc is about 1.19x faster.

So the pattern is consistent: StarRocks does better on the high-end ARM machine, while Arc does better on the more commodity c6a.4xlarge.

What the Numbers Actually Say

This is the first post in the series where the right takeaway is not "Arc wins" or "StarRocks wins." The right takeaway is narrower:

• If you're targeting a high-end analytical box like c8g.metal-48xl, StarRocks currently leads on ClickBench.
• If you're targeting a more realistic single-node budget machine like c6a.4xlarge, Arc currently leads.

That's a real result, and it is worth stating plainly.

It also lines up with what StarRocks is built for. This is not Elasticsearch trying to behave like a columnar analytics engine. This is not TimescaleDB stretching PostgreSQL into OLAP territory. StarRocks is an OLAP system competing in an OLAP benchmark, so a close or split outcome is credible.

The c7a.metal-48xl result is also worth noting even though we don't have a matching StarRocks score there. Arc lands at ×1.61, which keeps it in the same general performance band as the top of the leaderboard rather than falling off a cliff. The story here isn't that Arc can't compete. It's that the winning system changes with the machine class.

Why the Machine Matters

We should be careful not to over-explain what we can't prove from benchmark numbers alone. ClickBench tells us what happened, not every architectural reason why.

What we can say is simpler:

• StarRocks appears to extract more from the high-end c8g.metal-48xl configuration, especially on hot runs.
• Arc performs better on the c6a.4xlarge, which is closer to the kind of single-node machine many teams actually deploy first.
• The benchmark gap here is measured in tens of percent on combined score, not the one-order-of-magnitude gaps we saw against weaker analytical fits.

For a buyer, that's useful. It means this comparison is about workload shape and hardware budget, not about one system being obviously outclassed.

Queries are split by machine class. Ingestion is not.

Ingestion

For ingestion, the story is much less mixed.

One practical constraint matters upfront: StarRocks does not have a native macOS install path for this benchmark setup. We ran StarRocks in Docker, and we also ran Arc in Docker on the same macOS host to keep the comparison fair.

The ingestion protocols are different:

• Arc: MessagePack columnar over HTTP
• StarRocks: Stream Load over HTTP with JSON payloads

We are not going to pretend those are identical wire formats. We are going to state the measured result clearly.

Ingestion Results

We tested multiple ingestion settings instead of presenting a single cherry-picked point.

At the same 12 workers / 1K batch setup, Arc sustained 6,035,341 rec/s and StarRocks sustained 68,682 rec/s.

That puts Arc at about 87.9x higher throughput in the matched small-batch comparison.

Even after increasing StarRocks to 10K batches, Arc's 12 workers / 1K batch result is still about 9.0x higher on throughput while using 10x smaller batches.

If we compare Arc's 50 workers / 1K batch result against StarRocks's highest successful run at 50 workers / 50K batch, Arc is still about 7.4x faster while using 50x smaller batches.

This is not a narrow result. Under the tested Docker setup, Arc is substantially faster on sustained ingestion.

Tuning Context

StarRocks was highly batch-size sensitive.

At 12 workers / 1K batches, StarRocks sustained 68,682 rec/s.

At 12 workers / 10K batches, it reached 671,370 rec/s.

The highest successful run we recorded came from 50 workers / 50K batches, where StarRocks sustained 1,013,682 rec/s.

That context matters because it shows the result is not based on a weak or obviously under-tuned StarRocks configuration. StarRocks needed much larger batches before it approached its best observed throughput.

Stability Caveat

We also pushed StarRocks harder.

In the 50 workers / 50K batches regime, we also observed FE instability in a separate run. Throughput initially reached millions of records per second, then collapsed to zero after about 35 seconds while the FE service fell into repeated restart / FATAL behavior.

So we do not present that regime as a clean stable default. We report 1,013,682 rec/s as the highest successful StarRocks run we observed, with the explicit caveat that this tuning range also showed instability.

The Honest Caveat

If your buying decision is centered on high-end analytical hardware and your workload looks like the c8g.metal-48xl ClickBench profile, StarRocks currently has the stronger result. That's the honest read.

If your priority is a simpler single-node deployment on commodity hardware, Arc currently has the stronger result on c6a.4xlarge. That's also the honest read.

Arc still brings the same advantages we've been emphasizing throughout this series: single binary deployment, standard Parquet storage, and true cold benchmark methodology already implemented in the public ClickBench submission.

But this is not the post to pretend the answer is universal. It isn't.

Reproduce It Yourself

Every claim in this post comes from public benchmark data or public benchmark infrastructure.

• ClickBench results: benchmark.clickhouse.com — filter for Arc and StarRocks on the listed machines
• Ingestion benchmark harness: benchmarks/sustained_bench/main.go in https://github.com/Basekick-Labs/arc — Arc tested via MessagePack write, StarRocks tested via HTTP Stream Load using the starrocks/allin1-ubuntu Docker image
• Arc's run script: https://github.com/ClickHouse/ClickBench/tree/main/arc
• True cold migration issue: https://github.com/ClickHouse/ClickBench/issues/793
• Arc on GitHub: https://github.com/Basekick-Labs/arc

Bottom Line

This is the sixth post in the Arc ClickBench series, and it's the first one where the answer genuinely depends on the machine class.

StarRocks currently leads on the high-end ClickBench box. Arc leads on c6a.4xlarge and on sustained ingestion by a wide margin.

Arc also already runs true cold benchmarks, while StarRocks is still on the migration list in issue #793.

So the honest summary is simple: on ClickBench queries, this one depends on the machine. On ingestion, it doesn't.

Next up: DuckDB.

---

Get started:

• Arc documentation
• https://github.com/Basekick-Labs/arc
• Join the Discord

Questions or challenges? Find us on Discord or open an issue on https://github.com/Basekick-Labs/arc/issues.