Druid Adapter

Generate Druid SQL from your model, with subqueries in place of CTEs.

What the adapter emits

  • Identifiers in "double quotes"; bare column names in expressions are lowercased.
  • No CTEs or temp tables. The per-fact subqueries that other dialects put in a WITH clause are nested inline as subqueries; blends still use a FULL OUTER JOIN.
  • Date parts with TIME_EXTRACT(x, 'YEAR'), TIME_EXTRACT(x, 'DOW') and so on.
  • The end of a between date filter is extended to the last hour of the day, so a filter through 2026-01-31 includes that day’s rows, and date filters are not pushed down greedily into every subquery.

Configuration

druid_cluster:
  adapter: druid
  name: Druid Cluster
  tier: hot
  protocol: http
  host: druid.example.com
  port: 8082

Connection fields

0sql never connects to Druid. Protocol, host and port are carried as metadata for your own application, which runs the SQL it gets back against the broker. 0sql never uses them. If a password does land in datasources.yml, zsql deploy strips it before building the archive.

Notes

  • Expressions are Druid SQL. APPROX_COUNT_DISTINCT_DS_HLL, TIME_FLOOR and LATEST are fine in expression.sql.
  • A natural hot tier. Druid usually holds recent, pre-aggregated data in front of a warehouse of record. Give its tables a low cost and a date partition so the planner routes recent-data queries there. See Semantic Routing.

Next Steps