Druid vs Databricks: Cube or Lakehouse

Databricks SQL cannot answer an event that is still only on a Kafka topic. That is not a latency complaint. It is eligibility. Photon reads Delta. Auto Loader watches files. Structured Streaming from Kafka is a separate job that has to stay up. Until a row is in a table, the warehouse is out.

Apache Druid is eligible earlier. A Kafka supervisor indexes the topic into segments. Realtime tasks answer during the in-flight hour. Then handoff. Then Historicals. The dashboard hits local bitmaps, not Parquet.

Those are different products that happen to accept a GROUP BY on minute and country. Databricks SQL uses date_trunc:

SELECT
  date_trunc('MINUTE', event_time) AS minute,
  country,
  COUNT(*) AS events,
  SUM(revenue) AS revenue
FROM page_views
WHERE event_time >= current_timestamp() - INTERVAL 1 HOUR
GROUP BY 1, 2

Druid SQL uses __time and a time-floor (TIME_FLOOR / FLOOR(__time TO MINUTE)). Same grain. Not the same dialect, not the same data path, not the same team.

ClickHouse® vs Druid and ClickHouse vs Databricks are engine comparisons. This page is cube versus lakehouse: who is allowed to run the query, who owns Unity, and who still has to publish an HTTP tile for an app.

The warehouse waits for a table

Auto Loader incrementally ingests files from cloud storage into Delta with checkpoints. If the producer writes Kafka and nothing dumps objects, Auto Loader has nothing to see. The Kafka-to-Delta path is Structured Streaming or a Lakeflow pipeline: compute you leave running so offsets advance.

A serverless SQL warehouse then runs Photon over those files. Databricks documents startup as typically 2 to 6 seconds (SQL warehouse types). Snowflake's virtual-warehouse minimum billing charge is 60 seconds (warehouse considerations). Faster resume is still JDBC/ODBC for BI. It is not a per-request token on an HTTP pipe.

Druid does not wait for a file. The supervisor spec is the ingest job:

{
  "type": "kafka",
  "dataSchema": {
    "dataSource": "page_views",
    "timestampSpec": { "column": "event_time", "format": "iso" },
    "dimensionsSpec": { "dimensions": ["country", "path"] },
    "metricsSpec": [
      { "type": "count", "name": "events" },
      { "type": "doubleSum", "name": "revenue", "fieldName": "revenue" }
    ],
    "granularitySpec": {
      "segmentGranularity": "HOUR",
      "queryGranularity": "MINUTE",
      "rollup": true
    }
  },
  "ioConfig": {
    "topic": "page_views",
    "consumerProperties": { "bootstrap.servers": "kafka:9092" },
    "taskCount": 4,
    "replicas": 1,
    "taskDuration": "PT1H"
  },
  "tuningConfig": {
    "type": "kafka",
    "maxRowsPerSegment": 5000000
  }
}

maxRowsPerSegment defaults to 5,000,000 post-aggregation rows. Kafka handoffConditionTimeout defaults to 900,000 ms (15 minutes). If handoff stalls, the dashboard reads a hole. That is the freshness contract you buy with a cube.

Closed cube vs Delta + Unity

Rollup at ingest collapses rows that share __time plus the declared dimensions. Add campaign six months later and you reindex history, or you live with two schemas. Bitmaps make country IN (...) cheap when those columns were dimensions. Joins are lookups. Multi-table mart SQL is not the design center.

Delta is Parquet plus a transaction log. ALTER TABLE ADD COLUMN is legal. Photon still scans files. Liquid clustering and predictive IO help selective reads. They are not a bitmap on every dimension. Unity Catalog owns names, grants, and lineage across workspaces. That identity plane is why Databricks wins RFPs that a Druid cluster never sees.

Lakehouse Real-Time (Lakehouse//RT) is Databricks's Beta serverless warehouse type for sub-second, high-concurrency SELECT-only reads against Unity Catalog tables (warehouse types). Treat it as a serving SKU in preview. It does not ingest Kafka, does not replace a supervisor, and does not publish HTTP tokens.

The staffing difference

Plus metadata SQL, deep storage, and ZooKeeper or equivalent. Imply exists because this list is a team. Apache Druid alternatives is mostly people looking at that table.

Databricks's cost is jobs plus the warehouse: streaming lag, Delta OPTIMIZE, Unity grants, warehouse sizing, Photon on unclustered JSON. Fewer daemons. More conversations with the platform team that already owns Spark. Databricks alternatives when the lakehouse is the overbuy for a single product tile.

DBU hours vs Historicals that never sleep

Serverless SQL warehouses bill a fixed DBU-per-hour rate by warehouse size. Microsoft's published SQL Serverless table lists a Small warehouse at 12 DBU/hour (Azure Databricks serverless DBU consumption). Dollar-per-DBU rates sit in the cloud price list and vary by cloud, region, and tier (Databricks SQL pricing). Do not treat a Lakehouse Real-Time SKU rate as the SQL Serverless rate.

The numbers below are worked examples. Assumed: 12 hours/day, 22 days/month, one Small left up for those hours.

An internal workbook that sleeps between runs is not 12 hours of DBU. Druid still paid for Historicals and ingest all month. Databricks wins. Stop building a cube.

A customer tile that refreshes every 15 seconds cannot sleep. 12 DBU/hour × 12 × 22 = 3,168 DBU/month for that one Small, before Jobs compute that writes Delta. Multiply 3,168 by the serverless SQL list price in your region. At 50 concurrent tenants, Photon on 8 GB of last-hour files is a bigger warehouse, not a cheaper one. Druid's marginal cost of another 15-second refresh is ~0 once segments are local. That is the economic argument for a serving cube, and it is why you still need something other than a warehouse if the consumer is an app.

The product tile is not a SQL warehouse

Neither the Broker nor JDBC is an HTTP contract with a tenant token. Tinybird takes the same Kafka or HTTP events and publishes the grain as a pipe. ClickHouse® SQL, ORDER BY as the skip index, a resource token on the endpoint.

The Kafka connector reads the topic. Offsets and retries are the connector's job, not an Overlord plus MiddleManagers. If the producer is the app, the Events API accepts JSON over HTTP. Documented default: 100 requests per second per datasource. Batch NDJSON when you need more rows per request. Per-request size is on that page (10 MB on Free). Acknowledgements are typically under 2 seconds (HTTP 202); wait=true waits for commit. There is no Auto Loader wait for a file to land.

Parameter names must not collide with columns. The tile filters on tenant_id in the table, so the query param is tenant:

DESCRIPTION >
    Per-tenant last-hour page views. Product tile.

NODE tenant_tile
SQL >
    %
    SELECT
        toStartOfMinute(ts) AS minute,
        country,
        count() AS events,
        sum(revenue) AS revenue
    FROM page_views
    WHERE
        tenant_id = {{ String(tenant, 'demo') }}
        AND ts >= now() - INTERVAL 1 HOUR
    GROUP BY minute, country
    ORDER BY minute, country

TYPE ENDPOINT

Auth is a resource token on that pipe. npx tinybird preview gives the PR its own data. Production is npx tinybird deploy. Resend publishes product analytics at 62 ms p90 on this serving shape (Resend customer story).

The 15-second tile that keeps a Small warehouse up (3,168 DBU/month in the worked example) is a Developer plan plus vCPU overage at $0.0002 per vCPU-second above baseline (Tinybird pricing) once a rollup exists. The meter is compute on a small aggregated table, not 12 DBU left on.

You do not get Druid bitmaps tuned by an OLAP CoE, or Unity, Spark jobs, and Photon joins across the lake. Wrong buy for a 1-hour internal workbook on Delta you refuse to index. Wrong buy if a Druid team already runs supervisors and the dimension set is frozen. Right buy when the cube keeps changing, freshness must be seconds, and the consumer is an app.

Keep the lake. Stop using it as a product API

Use Databricks when Unity, Spark jobs, and BI on Delta already exist. Use Druid when a dedicated OLAP team already knows supervisors and the query set is a closed cube. Use Tinybird when that same grain has to be an HTTP endpoint with a tenant token.

Frequently Asked Questions (FAQs)

Are Apache Druid and Databricks alternatives?

No. Druid indexes a stream into segments and answers from local data. Databricks SQL scans Delta in a warehouse. If the event is still in Kafka and not in a table, the warehouse cannot answer.

When is Databricks cheaper than Druid?

An internal workbook that wakes a Small serverless warehouse a few times a day. Druid's always-on Historicals lose that comparison. A customer tile that refreshes every 15 seconds keeps the warehouse up. Then the cube's fixed cluster, or another serving OLAP, is the cost conversation.