Infrastructure

Terraform provisions the Snowflake databases, schemas, warehouses, and roles that the three dbt projects run against, plus the AWS resources their ingestion Lambdas depend on. It does not own table structure — that's Migrations.

Two Terraform Cloud workspaces per environment-ish split matter here: env-staging is the source of truth, env-prod mostly symlinks back to it, and env-master/env-ci cover organization-level Snowflake resources and CI configuration respectively.

At a glance


IaC	Terraform (AWS + Snowflake + GCP resources, one state per environment)
Snowflake roles	6 functional roles (`AIRBYTE`, `DBT`, `BI`, `ETL`, `N8N`, `READONLY`)
Environments	`env-staging`, `env-prod` (symlinked to staging), `env-master`, `env-ci` — no `env-dev`
Table DDL	Owned by `schemachange`, not Terraform

Start here

How does data actually get from S3 into Snowflake, and what happens when it fails? Data flow & failure modes — the real ingestion path, plus the alerting gaps in it worth knowing about.
What can each Snowflake role do? Snowflake resources & RBAC — the 6 roles, warehouses, and the Terraform/schemachange ownership line.
What AWS resources back this? AWS resources — S3 buckets, SQS, IAM.
Why does prod mirror staging? Environments — the symlink convention and what it does and doesn't let you diverge.
Where do keys and passwords actually live? Secrets & SSM conventions — naming convention and the placeholder-then-manual-fill pattern.