What Apache Pinot migrations do you handle?

Druid → Pinot (user-facing-latency requirements that Druid can't hit), ClickHouse → Pinot (multi-tenant isolation needs), realtime-to-hybrid table conversion (adding offline batch tier to existing realtime workload), self-managed → StarTree Cloud (operational outsourcing), upsert-workload migrations leveraging Pinot's primary-key support. For the engine-decision phase, see Pinot consulting .

Druid → Pinot — when does this happen?

When the workload outgrows Druid's roll-up-segment model. Triggers: (a) user-facing analytics need sub-100ms p99 latency that Druid can't consistently deliver, (b) multi-tenant SaaS requires Pinot's tag-based server segmentation, (c) raw-row drill-down is needed (Druid roll-up is destructive). Re-modelling required: Druid time-partitioned segments → Pinot star-tree-indexed tables, supervisor tasks → LLRT consumers.

ClickHouse → Pinot — what's the trigger?

Multi-tenant SaaS isolation. ClickHouse handles single-tenant analytics excellently but multi-tenant noisy-neighbour prevention is a project; Pinot's tag-based server segmentation does it natively. Also: user-facing dashboard p99 budgets that ClickHouse cold-cache cost can't hit. Migration: schema re-modelling (MergeTree → star-tree tables), Kafka stream re-targeting, multi-tenant table-per-tenant or shared-table-with-tenant-column design.

Realtime-to-hybrid table conversion — what's involved?

Hybrid tables combine LLRT realtime ingestion with batch-built offline segments. Common pattern: realtime for last 7-30 days, offline for historical depth. Conversion sequence: (1) configure offline table with matching schema, (2) build Spark/Hadoop job for batch segment generation, (3) upload to deep storage, (4) configure hybrid table to federate queries across both, (5) shrink realtime retention window. Queries transparently span both segments.

Self-managed → StarTree Cloud — economics?

StarTree Cloud handles Controller / Broker / Server / Minion operations, Helix coordination, deep storage, multi-tenancy. Wins for: fast time-to-value, multi-tenant SaaS isolation (StarTree built specifically for this), small ops teams. Self-managed wins for: sustained workloads where reserved-instance EC2 beats StarTree pricing, regulatory placement requirements, or teams with deep K8s + Helix expertise.

Helix coordination — how to manage during migration?

Apache Helix manages segment assignment in Pinot. During migration, Helix state needs careful handling: rebalances during cutover create extra load, segment assignments need consistent ZooKeeper state, and recovery from Helix-state mismatch is a real operational risk. We design migration to avoid Helix rebalances at peak load and validate state consistency before cutover gates.

Cutover playbook for zero-downtime?

Standard: (1) provision Pinot target with sized topology, (2) dual-load realtime stream to both source and Pinot, (3) bulk-load historical via batch segment generation, (4) wait for replica lag to settle, (5) flip reads — observe p99 latency + error rate, (6) quiesce writes on source briefly, (7) promote Pinot, (8) 24-48 hour soak, (9) decommission source. Helix state validation at each gate.

Sound familiar?

▸ Druid → Pinot — user-facing analytics need sub-100ms p99 and Druid roll-up is the bottleneck; Pinot's star-tree is the obvious answer but re-modelling is real work.
▸ Multi-tenant isolation — your SaaS analytics platform needs per-tenant noisy-neighbour prevention; ClickHouse can't do it cleanly, Pinot can.
▸ Realtime → Hybrid table — your retention window is growing and offline batch tier is overdue.

JusDB Apache Pinot migration team delivers tested cutover runbooks. Book a Pinot migration scoping call →

Tested cutover playbooks

Apache Pinot Migration Services

In short: An Apache Pinot migration covers Druid → Pinot user-facing-latency moves, ClickHouse → Pinot multi-tenant isolation, realtime-to-hybrid table conversion, and self-managed → StarTree Cloud. Each runs a tested runbook — schema re-modelling to star-tree tables, Kafka stream re-targeting, historical backfill — then a Helix-state-validated cutover with a defined rollback procedure.

Druid → Pinot user-facing-latency migrations, ClickHouse → Pinot multi-tenancy, realtime-to-hybrid table conversion, self-managed → StarTree Cloud — executed with Helix-state-validated cutovers. See Pinot consulting for the engine-decision phase.

Apache Pinot migrations we handle

Each path has a tested runbook — instrumented cutover, Helix-state validation, defined rollback procedure.

Druid → Pinot (user-facing)

Sub-100ms p99 latency requirements that Druid can't consistently hit. Re-modelling from time-partitioned segments to star-tree-indexed tables, supervisor → LLRT consumer conversion.

ClickHouse → Pinot (multi-tenant)

Tag-based server segmentation for SaaS tenant isolation. Schema re-modelling from MergeTree to star-tree tables, Kafka stream re-targeting.

Realtime → Hybrid Table

Add offline batch tier to existing realtime workload — Spark segment generation, deep-storage upload, hybrid table federation. Realtime retention window shrinks accordingly.

Self-Managed → StarTree Cloud

Operational outsourcing — Controller/Broker/Server/Minion management, Helix coordination, multi-tenant isolation handled by StarTree.

Upsert Workload Migration

Pinot's primary-key upsert support since 0.6.x. Migration from append-only-with-dedup patterns (ClickHouse ReplacingMergeTree, Druid roll-up) to native upserts.

Version Upgrades

Cross-major Pinot upgrades with Helix state preservation, rolling deployment of Controller / Broker / Server tiers, segment-assignment validation.

Pinot migration — common questions

Ready to plan the Pinot migration?

Book a 30-minute scoping call. We'll review source topology, sketch the cutover sequence, and propose the engagement shape.

Related Apache Pinot Services

Explore more ways our Apache Pinot experts can help with your database infrastructure.

Apache Pinot Consulting Apache Pinot Performance Tuning Apache Pinot Kubernetes

View all Apache Pinot services