Question 1

What Apache Druid migrations do you handle?

Accepted Answer

Pinot → Druid (time-series-roll-up workload consolidation), Snowflake → Druid (cost-driven warehouse migration for time-series-heavy workloads), self-managed → Imply Polaris (operational outsourcing with Pivot visualisation), Druid version upgrades, ZooKeeper migration / coordination management. For the engine-decision phase, see Druid consulting.

Question 2

Pinot → Druid — when does this make sense?

Accepted Answer

When workload is time-series-heavy with long retention and the roll-up storage efficiency genuinely matters. Pinot's star-tree is excellent for user-facing analytics but creates storage overhead for pure time-series; Druid's destructive roll-up at ingestion is more storage-efficient for write-once-aggregate workloads. Migration: schema re-modelling from star-tree tables to time-partitioned segments, LLRT consumer → Kafka indexing supervisor.

Question 3

Snowflake → Druid — what's the playbook?

Accepted Answer

Cost-driven, time-series-specific. When Snowflake virtual-warehouse credits run hot for sustained time-series analytics (observability, ad-tech, network telemetry), Druid's purpose-built architecture is dramatically cheaper. Sequence: workload audit (Snowflake queries that are time-series-shaped), schema re-modelling, ingestion redesign (Snowpipe → Kafka or batch), dual-write transition, cutover. Sustained-workload savings typically 50-70%.

Question 4

Self-managed → Imply Polaris — economics?

Accepted Answer

Imply Polaris handles Coordinator / Overlord / Historical / Broker tier operations + Pivot visualisation layer. Wins for: fast time-to-value, integrated BI replacement (Pivot), small ops teams. Self-managed wins for: sustained workloads where reserved-instance economics beat Polaris pricing, regulatory placement requirements. We model both before recommending the direction.

Question 5

Druid version upgrades — what's the risk profile?

Accepted Answer

Druid version upgrades are operationally significant — Coordinator + Overlord need careful orchestration, Historical replicas need rolling deployment, deep-storage segment compatibility needs validation. We sequence: (1) test query compatibility on staging copy, (2) validate segment-format compatibility, (3) rolling-upgrade Historicals first, (4) upgrade Coordinator + Overlord last, (5) post-upgrade reindex if necessary. Most upgrades are clean but the operational sequence matters.

Question 6

ZooKeeper coordination — how to manage during migration?

Accepted Answer

Druid uses ZooKeeper for coordination state. During migration, ZK state needs careful handling: rebalances at peak load create extra coordinator work, segment-assignment state must be consistent. Most migration patterns avoid ZK rebalances during cutover — we sequence the migration to align with low-load windows and validate state consistency at each gate before promoting traffic.

Question 7

Cutover playbook for zero-downtime?

Accepted Answer

Standard: (1) provision Druid target with sized tiers, (2) bulk-load historical via batch segment generation + deep storage upload, (3) establish realtime via Kafka indexing supervisor, (4) wait for segment-fetch + replica lag to settle, (5) flip reads — observe p99 + error rate, (6) quiesce writes on source briefly, (7) promote Druid, (8) 24-48 hour soak, (9) decommission source.

Apache Druid Migration Services

Apache Druid migrations we handle

Druid migration — common questions

Ready to plan the Druid migration?