Datasources

datasources.yml describes each warehouse a project’s tables live in. The adapter picks the SQL dialect the service emits; the tier tells the planner which copy of the data to prefer. 0sql never connects to a warehouse: the connection fields ride along as metadata for your own application, and secrets never leave your machine.

The file

The commented template zsql init writes:

# The warehouses this project's tables live in. One entry per datasource,
# keyed by a short id that table files refer to. Connection details that
# are secrets (password, tokens, keys) are stripped before deploy, and
# nothing here is ever used by 0sql.
#
# warehouse:
#   name: Warehouse
#   adapter: postgres            # duckdb | postgres | snowflake | bigquery | databricks | trino | mysql | sqlserver | ...
#   tier: hot                    # hot | warm | cold; the planner prefers hotter tiers
#   host: localhost
#   port: 5432
#   database: analytics
#   username: analyst
#   schema: public
#
# local:
#   name: Local DuckDB
#   adapter: duckdb
#   tier: hot
#   file: ./data/analytics.duckdb

A filled-in file for the running TPC-DS example:

tpcds:
  name: TPC-DS (Postgres)
  adapter: postgres
  tier: cold
  host: localhost
  username: tpcds_user
  database: tpcds

The top level maps a key to its settings. The key (trimmed, lower-cased) is the datasource uid; table files refer to it with datasource: tpcds. The file is required, needs at least one entry, and refuses a repeated key.

Adapters

athena  bigquery  clickhouse  databricks  druid  duckdb  mysql
postgres  redshift  snowflake  sqlite  sqlserver  trino

Any other string fails the deploy with Datasource errors: adapter '<x>' is not supported.

The adapter controls the SQL the service emits for that datasource: identifier quoting (" for most, backticks for bigquery, clickhouse, databricks and mysql, [...] for sqlserver), date literals and truncation functions, which words are reserved and which functions count as aggregates in your expressions, and join support (mysql has no FULL JOIN; druid has no CTEs). There are no adapter-specific settings to write in the project; the adapter name is the whole configuration.

Tiers

tier ranks copies of the same data. When a measure is reachable on a hot datasource and a cold one, the planner routes to the hot one. Use it when a fast store holds a subset or an aggregate of what the warehouse holds. Routing rules are on Semantic routing.

Secrets

The service never opens a connection, so it never needs credentials. On zsql deploy, datasources.yml is shipped with these keys removed:

password  private_key  personal_access_token  secret_access_key
access_key_id  oauth_client_secret  oauth_client_id  api_key

Keep secrets out of the file anyway. Nothing in the project needs a working credential, because 0sql never opens a connection; the fields are there for your application to read.

Next steps

• Datasources in the semantic model
• Modeling with zsql
• Semantic routing