Question 1

What does StarRocks performance tuning cover?

Accepted Answer

Primary-key model upsert tuning (memory budget, persistent index strategy), materialized view refresh-policy optimization (async vs sync, partition-aware refresh), Stream Load / Routine Load throughput tuning, FE memory + BE memory limit balancing, query cache strategy, vectorised execution + parallel_fragment_exec_instance_num tuning, Iceberg external-catalogue query optimization. Deliverables include before/after benchmarks.

Question 2

Primary-key model upserts are slowing — why?

Accepted Answer

Primary-key model maintains an in-memory index by default — memory budget grows with table size. Once persistent_index isn't enabled, large primary-key tables overflow memory. Fix: enable persistent_index, tune persistent_index_block_cache_capacity, audit upsert batch sizes (small batches create more random I/O), evaluate whether the workload actually needs primary-key model or if duplicate / aggregate would fit.

Question 3

Materialized view refresh strategy — async or sync?

Accepted Answer

Async MV (default): refresh on schedule or partition-arrival, query optimizer rewrites queries to use the MV transparently. Sync MV: refreshed on every base-table write, lower latency, higher write cost. Most production deployments use async with partition-aware refresh for predictable cost. We audit slow-query patterns to determine which queries actually benefit from MVs and at what refresh cadence.

Question 4

Stream Load throughput is hitting a wall — what to tune?

Accepted Answer

Common bottlenecks: max_load_memory_limit per node, parallel_load_instances on BE, FE load-balancing strategy across BEs, network bandwidth between client and BE. For high-throughput ingestion: split big batches across multiple parallel Stream Load calls, tune memory headroom on BE for batch buffering, monitor system.load_history for queue depth and rejection rates.

Question 5

FE vs BE memory tuning — what's the split?

Accepted Answer

FE: metadata + query planning — typically 8-16GB sufficient, increase only if metadata grows large (many partitions, many MVs). BE: storage + execution — sized for working-set + query memory. Per-query memory via mem_limit setting balances against concurrent_query limit. Tablet count per BE drives FE metadata size — sometimes the fix is reducing tablet count, not increasing memory.

Question 6

CelerData Cloud vs self-managed sizing?

Accepted Answer

CelerData Cloud handles FE/BE/CN scaling automatically; you just pick tier sizes. Self-managed requires explicit sizing per tier and tablet-count planning. See StarRocks consulting for the architecture-decision phase including managed-vs-self-managed economics.

Question 7

Does performance tuning include code changes?

Accepted Answer

Yes — query rewriting, materialized view DDL, table-model selection are part of the engagement. Schema-level changes (changing primary-key columns, partition strategy) require coordination with engineering. Configuration changes are applied staging-first with validation gates before production rollout.

StarRocks Performance Tuning

What our StarRocks perf tuning covers

StarRocks perf tuning — common questions

Ready to fix StarRocks performance?