How StarRocks 4.1 Simplifies Operations and Boosts Production Performance

High‑performance analytics has always been StarRocks' core strength, but performance alone does not guarantee stable production. Large‑scale deployments, especially multi‑tenant scenarios, commonly face static data distribution that cannot adapt to business changes, escalating data skew, costly repairs, and a steep learning curve for configuring colocation, bucket numbers and distribution keys.

Key capabilities introduced in StarRocks 4.1

Automatic multi‑tenant data management : Enable with enable_range_distribution. The system automatically splits tablets along sort‑key ranges when a tablet exceeds a capacity threshold, eliminating the need to modify schema, adjust SQL, or reload data.

Large‑capacity tablets : In the compute‑storage separation architecture, a single tablet can scale to about 100 GB , reducing the number of tablets, FE metadata pressure, and import/compaction overhead.

Fast Schema Evolution v2 : DDL operations such as adding columns or changing types complete in seconds, with execution time independent of tablet or partition count.

Cache observability and latency control : Query‑level and cluster‑level cache hit rates are exposed via Audit Log, Prometheus BE metrics and SQL Profile I/O metrics; cache warm‑up and amplification reduction are integrated into the diagnostic stack.

Iceberg v2/v3 enhancements : Native SQL DELETE on Iceberg tables, support for the new Variant type, and incremental materialized views that refresh based on version ranges.

Additional improvements : Inverted index for compute‑storage separation, Skew Join v2 with histogram and NULL‑skew awareness, recursive CTE, window function array support, and FULL OUTER JOIN USING clause.

Automatic multi‑tenant data management in depth

When enable_range_distribution is turned on, StarRocks monitors data distribution changes and automatically splits a tablet that exceeds a preset capacity into smaller tablets. The split boundaries are derived from the sort‑key range, guaranteeing query correctness. This process runs entirely in the background; users do not need to modify table structures, rewrite SQL, or reload data.

In a benchmark using a 200 GB dataset with 32 concurrent threads, the adaptive range‑based distribution achieved 1.86× the throughput of static hash distribution, while the P99 latency dropped from 36.6 s to 11.5 s .

Large‑capacity tablets

By allowing a tablet to grow to roughly 100 GB, the number of tablets in a cluster is dramatically reduced. Fewer tablets lower the Front‑End (FE) metadata management load and cut scheduling and resource‑management overhead. Import and compaction operations also become lighter because fewer tablets are involved. For non‑partitioned primary‑key tables that cannot be time‑partitioned, the larger tablet size makes bucket number selection easier, especially when combined with the dynamic distribution mechanism.

Fast Schema Evolution v2

DDL operations such as adding columns or altering column types now modify only FE metadata, achieving true second‑level schema changes regardless of the number of tablets or partitions. This eliminates the long‑running DDL pauses that previously plagued large tables.

Cache observability enhancements

Cache hit rates can be observed at the query level via Audit Log and at the cluster level via Prometheus BE metrics. These metrics are also integrated into SQL Profile, providing end‑to‑end visibility. Cache warm‑up support enables controlled pre‑warming of compute replicas, reducing cold‑start latency after scaling events. Reducing cache amplification mitigates performance spikes caused by compaction, data migration, or failure recovery.

Iceberg integration upgrades

StarRocks now supports native distributed DELETE on Iceberg tables, generating Position Delete files that comply with Iceberg V2 and committing them atomically. The new Variant type, introduced in Iceberg V3, is fully vectorized, avoiding the overhead of JSON‑as‑STRING parsing. Incremental materialized views for Iceberg tables refresh based on version ranges, delivering a 7–30× performance boost over traditional partition‑level refreshes on a 100 GB dataset.

These enhancements collectively aim to lower operational complexity, improve performance predictability, and provide richer diagnostics for production environments.