Sound familiar?
- ▸ Primary-key model upserts blowing up memory on BE nodes — the table fits the use case but you're hitting OOM during compaction, and the docs don't cover the working-set sizing that actually prevents it.
- ▸ Migrating from ClickHouse or Doris and need an honest view of what changes — the wire-protocol compatibility looks good on paper, but the production difference is in JOIN strategy, MV semantics, and ingestion architecture.
- ▸ CelerData Cloud vs self-managed — your finance team wants TCO numbers before the next renewal, and the StarRocks-Inc. comparison page is unsurprisingly optimistic about the cloud path.
JusDB StarRocks consultants give you the written decision document with real numbers from real deployments. Book an architecture review →
Strategic advisory — not execution
StarRocks Consulting Services
Schema-model selection, ingestion-pipeline design, materialized-view strategy, and lakehouse integration for StarRocks and CelerData — delivered as written recommendations and trade-off documentation. See the StarRocks hub for the broader services overview.
What our StarRocks consulting covers
Each deliverable is a written decision document, sized topology proposal, or costed trade-off analysis — never a Slack-thread recommendation.
Schema Model Selection
Primary-key vs aggregate vs duplicate vs unique model — chosen based on your actual write pattern (upsert vs append), read pattern (scan vs lookup), and storage budget.
Ingestion Pipeline Design
Stream Load, Routine Load (Kafka), Broker Load, Flink Connector, Spark Connector — chosen by freshness SLA and existing infrastructure, not by documentation order.
FE/BE/CN Topology
Frontend (metadata + planner), Backend (storage + executor), Compute Node (shared-data lakehouse architecture) — sized for query concurrency, scan size, and data freshness.
Materialized View Strategy
Async MV vs sync MV vs query-time rollup decisions based on slow-query analysis, not blanket pre-aggregation that bloats storage and slows ingestion.
Lakehouse Integration
Iceberg, Hudi, Delta Lake external-catalog setup, Iceberg-as-source vs Iceberg-as-cold-tier strategy, metadata-only vs full-load patterns — for hybrid lakehouse-warehouse architectures.
Capacity & Cost Planning
Growth modeling, shared-data vs shared-nothing decision (StarRocks 3.x onwards), elastic compute sizing, S3/OSS storage tiering, reserved-instance modeling for self-managed.
CelerData vs Self-Managed
CelerData Cloud (managed StarRocks) vs self-managed-on-EC2-or-K8s decision modeling, including the operational-burden offset and the feature-availability delta.
How a StarRocks consulting engagement is shaped
Four engagement shapes, each with a different deliverable.
1–2 weeks
Architecture Review
Deliverable
Topology recommendation, current-state risk register, schema-model audit, materialized-view sanity check, sized remediation roadmap.
When to pick this
Running StarRocks already and want a second-opinion audit before scaling or signing the next CelerData renewal.
1 week
Engine Decision
Deliverable
StarRocks vs ClickHouse vs Doris vs Pinot decision matrix with TCO model and per-engine risk profile.
When to pick this
Before committing to a real-time OLAP engine — head off the migration cost of choosing wrong.
1 week
Migration Strategy
Deliverable
Risk-graded migration plan — ClickHouse → StarRocks, Doris → StarRocks, or Druid → StarRocks — with cutover sequence and rollback gates.
When to pick this
Before committing to any operationally significant StarRocks migration.
2–3 weeks
Greenfield Design
Deliverable
Topology spec, capacity model, table-model layout, ingestion pipeline design, MV strategy, security baseline, ops runbook outline.
When to pick this
New StarRocks deployment from scratch and you want production patterns from day one.
Table model matrix — when each one fits
Rough decision shape before a real engagement. Actual recommendation depends on your workload.
| Table model | Fits when | Avoid when |
|---|---|---|
| Primary-Key model | Upsert-heavy CDC streams, slowly-changing dimensions, real-time updates with point lookups. | Memory budget is tight and write QPS is low — duplicate model is simpler. |
| Aggregate model | Pre-aggregated metrics, time-series rollups, you never need raw rows after ingestion. | You need raw-row drill-downs or ad-hoc filters — aggregation collapses what you can ask. |
| Duplicate model | Append-only fact tables, range-scan analytics, log analytics with no dedup requirement. | Source emits duplicates and you need exactly-once semantics — use primary-key. |
| Unique model | Upsert without the primary-key index memory cost, low write QPS. | High write QPS — primary-key model is strictly better since StarRocks 3.x. |