Athena Adapter

Generate Athena SQL from your model. Athena is the usual cold tier: history in S3 behind a hotter warehouse.

What the adapter emits

  • Identifiers in "double quotes"; bare column names in expressions are lowercased.
  • Date literals as DATE '2026-01-01'; grain truncation as DATE_TRUNC('month', x); parts with YEAR(x), DAY_OF_WEEK(x), DAY_OF_YEAR(x).
  • CTEs for the per-fact subqueries and a FULL OUTER JOIN when a query blends measures from two facts.

Configuration

athena_data:
  adapter: athena
  name: AWS Athena
  tier: cold
  region: us-east-1
  database: analytics
  catalog: awsdatacatalog
  workgroup: primary
  # access_key_id / secret_access_key: never here; your application holds them

Connection fields

0sql never connects to Athena. Region, database, catalog, workgroup and any S3 output location are carried as metadata for your own application, which runs the SQL it gets back with its own AWS credentials (an IAM role on your compute, or keys). 0sql never uses them. If keys do land in datasources.yml, zsql deploy strips access_key_id and secret_access_key before building the archive.

Notes

  • Expressions are Athena SQL. approx_distinct, arbitrary, array_agg and date_diff are fine in expression.sql.
  • Pair with a hot tier. Give the Athena tables a date partition covering the history they hold and a higher cost, so the planner routes recent-data queries to the hot tier and only history to Athena. See Semantic Routing.

Next Steps