Data Stack Diagram Guide

dbt and Snowflake architecture diagram: the stack drawn the way it runs

By the engineer who builds Datadef, from client work on data platforms · Reviewed August 21, 2026

Every modern data stack diagram on the internet is the same five logos in a row with arrows between them. It communicates the tool choice and nothing else, which is why it never survives a real question. The version worth drawing shows the layers inside the warehouse, the compute that runs them, the environments they run in, and the roles that separate them.

Try it free
8 min readFor analytics engineers documenting a Fivetran, Snowflake, and dbt stack

See it as a diagram

Everything below, as a diagram you can edit. Describe yours and see it in seconds.

279/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

Five bands, not five logos in a row

Loading: Fivetran, Airbyte, or a custom extractor writing into raw schemas, one schema per source, with the sync frequency on each edge. Warehouse: Snowflake, drawn as storage and compute separately for reasons covered below. Transformation: dbt models organised into layers. Orchestration: Dagster, Airflow, Prefect, or dbt Cloud jobs. Consumption: Looker, Tableau, Metabase, or Superset, plus reverse ETL if the marts feed operational tools.

Draw them as horizontal bands with the flow going down or right, and keep each tool inside exactly one band. The instinct to give the orchestrator a central box with arrows to everything produces a spider, and orchestration reads better as a band alongside the flow with dashed control edges.

Data quality belongs somewhere explicit. dbt tests run inside the transformation band; an observability tool such as Monte Carlo watches from the side. Drawing quality checks where they actually execute is the difference between a diagram that helps during an incident and one that does not.

The Snowflake thing every diagram gets wrong

A Snowflake warehouse is a compute cluster. It is not where the data lives. Data lives in databases and schemas; warehouses execute queries against them. Diagrams that draw one Snowflake box labelled warehouse collapse the two concepts that Snowflake spent its whole architecture separating.

Draw databases and schemas as the storage side, for example RAW, ANALYTICS, and a per-developer sandbox, and draw the virtual warehouses as compute nodes attached to workloads: one for loading, one for dbt transformation, one for BI. Put the size and the auto-suspend setting on each. Those two numbers explain most of the cost conversation, and they are invisible in the logos-in-a-row version.

Add the role hierarchy if the review is about access. A loader role writing to RAW, a transformer role owning ANALYTICS, and a reporter role with read on marts is three nodes that answer a long list of questions. Snowflake grants are hierarchical, so the picture is small.

dbt is a layer, not a box

A single dbt logo in the middle of an arrow says the team uses dbt and nothing else. The useful rendering is the model layers: sources, staging models named stg_, intermediate models named int_, and marts holding fct_ and dim_ models. Draw them as a stack inside the warehouse, because that is literally where they run, as SQL executed by Snowflake compute.

Materialisation matters on the diagram: views cost nothing to store and everything to query, incremental models carry a merge strategy and a lookback window, snapshots capture slowly changing dimensions. Put the materialisation on each layer, and the performance conversation stops being guesswork.

Do not attempt the model-by-model graph on an architecture diagram. Four hundred models is a lineage view, not an architecture, and it belongs in a column-level lineage picture rather than on the canvas that describes the platform. Exposures are the exception worth drawing: they name the dashboards that depend on specific marts, which is the coupling between the data team and everyone else.

That rule is a shipped default here rather than advice. When a repository is synced with an architecture focus, the file selector caps dbt model files at three while allowing sixteen infrastructure files, out of a total budget of forty files and 250KB. The reasoning is the same as the reasoning above: a hundred model files would win the budget on volume and starve the classes that actually describe the platform, and three models are enough to establish the naming convention and the materialisation style without pretending to be the graph.

Environments, and the icons for all of it

Development and production are usually separate databases or separate schemas with the same model code, and which one you chose changes how a reviewer reads every arrow. Draw the environment split once, at the warehouse level, and note whether CI builds run against a clone. Zero-copy clones are cheap and widely used, and a reader who does not know one exists will assume the CI story is worse than it is.

On icons, the 32-file data tool set covers dbt, Snowflake, Fivetran, Airbyte, Dagster, Airflow, Prefect, Looker, Tableau, Metabase, Superset, Segment, RudderStack, Monte Carlo, Spark, ClickHouse, Databricks and Elasticsearch, sitting next to 439 AWS, 624 Azure and 226 Google Cloud marks in a library of 2,098 files. A stack that mixes vendor tools with cloud services resolves in one pass instead of one download per logo.

Describe the stack and the canvas comes back with the bands, the model layers, and labelled edges. Export to PNG or JPEG for the stakeholder deck, or put a live embed in the analytics repository README so the picture updates with the canvas. For the version generated from the dbt project itself, see living diagrams from dbt.

FAQ

What belongs on a modern data stack diagram?

The loaders and their sync frequency, the warehouse split into storage and compute, the dbt model layers with their materialisations, the orchestrator, the BI tools, and the environment separation. Five logos in a row communicates the tool choice and nothing a reviewer can act on.

Should the diagram show every dbt model?

No. Show the layers, staging, intermediate and marts, with their naming conventions and their materialisations. A model-by-model graph is lineage rather than architecture, and once a project passes a few dozen models it stops being readable on an architecture canvas. Exposures are the exception worth drawing, because they name the dashboards that depend on specific marts.

How do I draw Snowflake warehouses versus databases?

As separate things, because they are. Databases and schemas hold the data; virtual warehouses are compute clusters that execute queries against them. Draw the databases on the storage side and the warehouses attached to the workloads that use them, with size and auto-suspend on each.

Do I need to show environments on the diagram?

Yes if anyone will ask how changes get tested, which they will. Show whether development and production are separate databases or separate schemas, and whether CI builds run against a zero-copy clone. That single detail changes how a reader interprets every arrow in the transformation band.

How do I keep the stack diagram current as models change?

Generate it rather than redraw it. A diagram built from the project itself updates when the project does, and pairing it with a live embed in the repository README means the picture people see is the one from the last sync. Adding a model does not reshuffle the picture either: the sync compares a fingerprint of the parsed structure, and nodes moved by hand keep the positions they were given.