Apache Druid is a distributed analytical database designed for event-oriented workloads requiring low-latency filtering and aggregation. It can ingest streaming and batch data, but it is not a transactional replacement for an operational database.

Core data model

Every datasource has a primary timestamp column. Dimensions support grouping and filtering; metrics are commonly values aggregated during ingestion or query. Data is stored in immutable, time-partitioned segments with columnar encoding and indexes. Corrections generally create replacement segments rather than mutate individual rows in place.

Rollup can combine rows sharing a configured time bucket and dimension values. It reduces row count only when records match that grain and removes individual-event access from the rolled-up datasource.

Service architecture

  • Router: routes requests to Brokers, Coordinators, or Overlords and may provide a unified console path.
  • Broker: distributes queries to data-serving processes and merges results.
  • Historical: downloads immutable segments from deep storage and serves them.
  • Coordinator: manages segment availability and placement.
  • Overlord: manages ingestion tasks.
  • MiddleManager/Indexer: executes native ingestion tasks, depending on deployment mode.

Druid also depends on deep storage for durable segment files, a metadata store, and coordination services documented for the deployed release. Back up and secure each dependency.

Ingestion paths

Streaming supervisors manage long-running ingestion from supported systems such as Kafka or Kinesis. Batch ingestion reads bounded input through native tasks or supported external engines. Define schema, timestamp parsing, transforms, filters, partitions, tuning, error handling, append/replace semantics, and interval scope explicitly.

Test late events, duplicates, source partition changes, parse errors, schema evolution, task restarts, segment handoff, and replacement. “Exactly once” should not be claimed without scoping source, ingestion, publication, and query semantics.

Query with SQL

Druid SQL uses Apache Calcite planning and translates supported queries to native execution or the multi-stage engine. Validate the exact SQL and release: unsupported constructs, joins, window functions, type behavior, null handling, and resource limits can vary.

SELECT TIME_FLOOR(__time, 'PT1H') AS hour,
       country,
       COUNT(*) AS events
FROM events
WHERE __time >= CURRENT_TIMESTAMP - INTERVAL '1' DAY
GROUP BY 1, 2
ORDER BY hour DESC, events DESC

This illustrative query assumes a datasource and column named events and country. Verify syntax and results on the deployed version.

Evaluate fit before production

Use representative data and query mixes. Measure correctness, source-to-query freshness, warm and cold latency percentiles, throughput, errors, partial results, scanned rows and segments, storage including replicas and indexes, ingestion recovery, and operator effort. Compare with alternatives using the same resources and acceptance criteria; see Druid versus Pinot.

Operate and secure the cluster

Do not expose a quickstart or console publicly. Configure authentication, authorization, TLS, network controls, secret management, least privilege, audit evidence, monitoring, backup, recovery, and upgrade procedures. Quickstart is for local learning, not a production topology.

Monitor query latency/errors, ingestion lag and failures, segment availability, replica health, heap/direct memory, garbage collection, disk, deep storage, metadata-store health, and capacity. Use workload-driven Druid tuning and dashboard evaluation for the next steps.

Originally published October 14, 2023; technically reviewed and substantially updated September 4, 2026.