Adapters

0sql emits SQL for 13 warehouse dialects. The adapter on a datasource picks which one.

Supported Adapters

IdentifierEngineIdentifier quoting
athenaAWS Athena"double quotes"
bigqueryGoogle BigQuery`backticks`
clickhouseClickHouse`backticks`
databricksDatabricks SQL`backticks`
druidApache Druid"double quotes"
duckdbDuckDB"double quotes"
mysqlMySQL`backticks`
postgresPostgreSQL"double quotes"
redshiftAmazon Redshift"double quotes"
snowflakeSnowflake"double quotes"
sqliteSQLite"double quotes"
sqlserverMicrosoft SQL Server, Azure SQL[brackets]
trinoTrino, Presto"double quotes"

Any other value fails validation with adapter '…' is not supported.

What an adapter controls

An adapter is a dialect. It decides the shape of the SQL you get back from /sql:

  • Identifier quoting, as in the table above. Quoted identifiers in an expression.sql keep their case; bare words are lowercased.
  • Date functions: how a truncate decorator becomes DATE_TRUNC('month', x), DATE_TRUNC(x, MONTH) or DATETRUNC(month, x), how year, month and day-of-week are extracted, and how a date literal is written.
  • Join support for blends: when a query mixes measures from two facts, the per-fact subqueries are combined with a FULL OUTER JOIN on their shared dimensions. MySQL has no FULL JOIN, so there the blend is a LEFT JOIN.
  • Subquery structure: CTEs everywhere except Druid, which gets nested subqueries.
  • Which bare words are columns: each dialect’s reserved keywords and aggregate functions decide what in an expression is a column reference and what counts as an aggregate.

There are no adapter-specific options to set in the project. Per-query overrides exist through the spec’s db_settings, not through YAML.

Common Configuration

Every datasource takes the same keys:

  • adapter (required), one of the identifiers above
  • name, display name (defaults to the key)
  • tier, hot, warm or cold; see Datasources
  • description
  • query_timeout and extra_query_params, carried as metadata for the caller
  • connection fields, carried as metadata

Connection fields and secrets

0sql never connects to your warehouse, so the connection fields on a datasource are carried as metadata for your own application. They are not validated, and 0sql never uses them.

Keep secrets out of the project anyway. If password, private_key, personal_access_token, secret_access_key, access_key_id, oauth_client_id, oauth_client_secret or api_key do land in datasources.yml, zsql deploy strips them before building the archive.

Next Steps