druid

Druid answers questions about billions of events in under a second. It sits between an event stream and a dashboard: Kafka or Kinesis feeds it, Druid indexes on the way in and pre-slices everything by time, so the query someone runs at noon does not scan the whole table. Apache 2.0, the entire engine, with no paid edition held back.

Running it is the real story. Druid is not one process, it is six: coordinator, overlord, broker, router, historical, and middle manager, plus ZooKeeper, a metadata database, and deep storage in S3. A single-server quickstart exists for a laptop. Production is a cluster, and it needs somebody who can explain why a historical node fell out of balance at 2am.

Solo devs and small teams should look at ClickHouse/ClickHouse or duckdb/duckdb first. Both give you most of the query speed in one binary with none of the coordination. Druid earns its complexity at streaming ingest with high dashboard concurrency, the point where a single node stops keeping up.

The catch is that there is no small Druid. You pay the full architecture on day one whether you store a million rows or a trillion, and the engineers who can debug it when it tips over are not cheap.