Snowflake

Snowflake warehouses modeled for trust and cost

Snowflake is one of the two warehouses we build marketing data platforms on. Its separation of storage and compute is powerful and financially dangerous in equal measure, so our Snowflake work pairs dbt modeling with the cost governance that keeps credits under control.

dbt modelingCredit governanceData sharing
Quick answer

Snowflake engineering: modeled warehouses with dbt, cost-governed compute, and data sharing, built by a team that ships marketing data platforms on it.

The warehouse bill nobody can explain

Snowflake credits burn silently: warehouses left running, oversized compute for trivial queries, and dashboards hammering unmodeled raw tables. Meanwhile metric definitions drift between dashboards until no two reports agree. Both problems have the same fix: a modeled, governed warehouse.

What we build with Snowflake

  • Warehouse architecture with dbt models that make metrics mean one thing
  • Compute sizing, auto-suspend, and resource monitors that cap burn
  • Ingestion from ad platforms, marketplaces, and product databases
  • Data sharing and secure views for clients and partner teams

How we work

  1. Model with dbt from day one; raw-table dashboards are debt

  2. Size warehouses per workload and let auto-suspend do its job

  3. Set resource monitors before the first surprise invoice

  4. Document models so analysts self-serve without guessing

Typical stack

SnowflakedbtAirflow / DagsterFivetran / custom ingestionLooker / Power BI

Frequently asked questions

Both are excellent; the decision usually follows your cloud, your team, and your pricing shape. Snowflake favors multi-cloud flexibility and granular compute control; BigQuery favors GCP-native stacks. We build on both weekly.

Yes. Most savings come from auto-suspend, warehouse rightsizing, and moving hot dashboards onto modeled marts, none of which change what users see except the speed.

Go deeper