ClickHouse Adapter

Generate ClickHouse SQL from your model, typically for a hot tier in front of the warehouse.

What the adapter emits

  • Identifiers in `backticks`; bare column names in expressions are lowercased.
  • Date literals as toDate('2026-01-01'); grain truncation as date_trunc('month', x); parts with toYear(x), toMonth(x), toDayOfWeek(x).
  • CTEs for the per-fact subqueries (no temp tables), window functions where a decorator needs them, and a FULL OUTER JOIN when a query blends measures from two facts.

Configuration

clickhouse_hot:
  adapter: clickhouse
  name: ClickHouse Hot Tier
  tier: hot
  protocol: https
  host: abc123.us-east-1.aws.clickhouse.cloud
  port: 8443
  database: analytics
  username: analyst
  # password: never here; zsql deploy strips it if present

Connection fields

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

Notes

  • Expressions are ClickHouse SQL. uniqExact, quantile(0.5)(x), argMax and countIf are fine in expression.sql.
  • Built for the hot tier. Give the ClickHouse tables a low cost and a date partition covering what they hold, so the planner routes recent-data queries here and falls back to the warehouse otherwise. See Semantic Routing.
  • Views work. A view or materialized view is referenced by physical_name like any table.

Next Steps