Question 1

What StarRocks migrations do you handle?

Accepted Answer

ClickHouse → StarRocks (Iceberg lakehouse integration), Doris → StarRocks (post-fork upgrades), Druid → StarRocks (user-facing analytics with primary-key upserts), self-managed → CelerData Cloud (managed-service operations), greenfield → StarRocks with Iceberg lakehouse from day one. For the engine-decision phase, see StarRocks consulting.

Question 2

ClickHouse → StarRocks — when does this make sense?

Accepted Answer

When you need primary-key upserts (StarRocks handles this natively; ClickHouse forces ReplacingMergeTree workarounds), tight Iceberg/Hudi lakehouse integration, or MySQL-protocol compatibility for client tooling. Migration sequence: schema redesign (ClickHouse MergeTree variants → StarRocks table models), data movement via Iceberg external catalogue or Stream Load, application-tier validation against MySQL-protocol clients.

Question 3

Doris → StarRocks migration — what's the path?

Accepted Answer

StarRocks forked from Apache Doris in 2020; both projects evolved separately. Migration is 'same family, different roadmap' — schema/SQL are largely portable, but materialized-view semantics, primary-key model behaviour, and lakehouse integration differ. Teams migrate when StarRocks' CelerData-driven roadmap or specific features (better primary-key model, Iceberg integration depth) outpace Doris' community-driven pace.

Question 4

Druid → StarRocks — when worth it?

Accepted Answer

When the workload needs primary-key upserts that Druid doesn't support, MySQL-protocol compatibility for analyst tools, or tighter lakehouse integration. Druid's time-series-roll-up strength matters less; StarRocks' star-schema + Iceberg story is the differentiator. Migration requires re-modelling — Druid's time-partitioned segment-based ingestion is very different from StarRocks' tablet-based architecture.

Question 5

Self-managed → CelerData Cloud — economics?

Accepted Answer

CelerData Cloud handles FE/BE/CN operations, scaling, backups, and upgrades. Wins for: fast time-to-value, small teams without K8s expertise, multi-cloud flexibility. Self-managed wins for: sustained workloads where reserved-instance EC2 beats CelerData pricing, regulatory placement requirements. We model both before recommending the migration direction.

Question 6

Iceberg lakehouse adoption — what's the StarRocks story?

Accepted Answer

StarRocks has best-in-class Iceberg integration via external catalogue — query Iceberg tables directly without ingesting, or use Iceberg as cold-tier with StarRocks internal tables for hot. The migration pattern: keep historical data in Iceberg on S3, hot working-set in StarRocks tablets, queries federate transparently. This is the canonical lakehouse architecture StarRocks targets.

Question 7

Cutover playbook for zero-downtime?

Accepted Answer

Standard sequence: (1) provision StarRocks target with FE/BE topology sized for the workload, (2) bulk-load historical via Stream Load or Broker Load, (3) establish dual-write or Routine Load from Kafka, (4) wait for replication lag to settle, (5) flip reads — observe error rate + latency, (6) quiesce writes on source briefly, (7) promote StarRocks, (8) 24-48 hour soak, (9) decommission source. Instrumented with Prometheus throughout.

StarRocks Migration Services

StarRocks migrations we handle

StarRocks migration — common questions

Ready to plan the StarRocks migration?