Question 1

Druid or Pinot — when does each one win?

Accepted Answer

Pinot wins when the workload is user-facing analytics with strict p99 latency budgets — the star-tree index gives sub-100ms aggregations on high-cardinality slice-and-dice that's genuinely faster than Druid for the same query class. Druid wins on time-series-heavy workloads with long retention and heavy roll-ups — its segment compaction story is more mature and the time-partitioned data model fits time-series analytics natively. Both can do both workloads; the question is which fits the dominant pattern.

Question 2

What about ingestion — Pinot LLRT vs Druid Kafka indexing?

Accepted Answer

Both are Kafka-native, both deliver second-level freshness. Pinot LLRT (Low-Level Real-time Table) consumers commit segments to deep storage incrementally; the consumer task and the ingestion topology are explicit. Druid Kafka indexing service uses supervisor tasks that automatically scale and rebalance — operationally simpler for steady workloads. Pinot is more explicit (sometimes a feature), Druid is more managed (sometimes a feature). Pick based on team familiarity and the level of ingestion-pipeline control you want.

Question 3

Star-tree vs roll-up — which is the right pre-aggregation strategy?

Accepted Answer

Star-tree (Pinot) is an index that pre-aggregates across declared dimension combinations at segment-build time — queries that match the index skip raw scanning entirely. Roll-up (Druid) aggregates rows at ingestion time, reducing storage and improving query speed at the cost of losing raw-row resolution. Star-tree preserves raw rows (you can drill down); roll-up is destructive (you can't go back to original granularity). For workloads that need both pre-aggregation speed and raw-row drill-down, Pinot star-tree wins. For pure pre-aggregated time-series with high compression goals, Druid roll-up is more efficient.

Question 4

Multi-tenancy — how do they compare?

Accepted Answer

Pinot has more mature multi-tenant patterns — tag-based server segmentation lets you isolate brokers and servers per tenant within a single cluster. Druid relies on lane-based query routing and Kubernetes-native isolation. For SaaS workloads with strict tenant isolation requirements (per-tenant latency SLAs, noisy-neighbour prevention), Pinot's model is more battle-tested at LinkedIn / Uber-scale deployments. Druid's model works but typically pushes more isolation work to the deployment layer.

Question 5

Managed cloud — Imply vs StarTree, what's the difference?

Accepted Answer

Imply Polaris is the managed-Druid offering — fully-hosted Druid with the Pivot visualisation layer included. StarTree Cloud is the managed-Pinot offering — built by the original Pinot creators with multi-tenant SaaS architecture. Both are mature; pick based on which engine you need. Imply integrates Pivot for the BI-tool-replacement experience; StarTree focuses on the data-platform infrastructure layer with looser BI integration (you bring your own viz). The choice usually mirrors the underlying engine choice rather than overriding it.

Question 6

What about Druid → Pinot or Pinot → Druid migration?

Accepted Answer

Both engines target similar workloads, so migrations between them are workload-shape-driven. Druid → Pinot is typical when user-facing latency requirements tighten (Pinot's star-tree wins for slice-and-dice). Pinot → Druid is typical when the workload is dominated by time-series with heavy roll-up needs. The data movement is straightforward (both consume from Kafka or batch deep storage); the application-tier rewrites (query syntax, dashboard integration, ingestion configuration) are the real cost. Most teams stay on the chosen engine and live with the trade-offs.

Dimension	Apache Druid 30+	Apache Pinot 1.x
Origin	Metamarkets (2011) — time-series-first design	LinkedIn (2013) — user-facing analytics-first design
Pre-aggregation	Roll-up — destructive aggregation at ingestion time	Star-tree — index that pre-aggregates per declared dimension set
Raw-row drill-down	Lost on roll-up (unless you ingest both raw and rolled-up data)	Preserved — star-tree augments raw data, doesn't replace it
Ingestion	Kafka indexing service (supervisor tasks, auto-scale)	LLRT (Low-Level Real-time Tables) + offline batch
Coordination	Coordinator + Overlord, ZooKeeper-based	Controller + Apache Helix + ZooKeeper
Query latency profile	Sub-second for time-series; degrades on high-cardinality dims	Sub-100ms p99 for slice-and-dice (star-tree advantage)
Multi-tenancy	Lane-based query routing, K8s-native deployment isolation	Tag-based server segmentation native — battle-tested at scale
Query languages	SQL + native JSON query API + Druid SQL	SQL + PQL (Pinot Query Language)
Indexing	Bitmap, dictionary, time-partitioned segments	Star-tree, inverted, sorted, range, JSON, text, geospatial, vector
Updates / upserts	Limited — append-mostly, segment-level overwrites	Upsert support since 0.6.x — primary-key based
Deep storage	HDFS, S3, GCS, Azure Blob	HDFS, S3, GCS, ADLS
Managed cloud	Imply Polaris — Druid + Pivot visualisation	StarTree Cloud — managed multi-tenant Pinot

Apache Druid vs Apache Pinot

Feature matrix

When Druid wins

When Pinot wins

Migration paths between Druid and Pinot

Druid → Pinot

Pinot → Druid

Either → managed cloud

Common questions

Need a written Druid-vs-Pinot decision?