Snowflake Architecture Diagram: Warehouses, Data Sharing & Cost Governance (2026)

Snowflake architecture diagrams exist to make one fact legible at a glance: storage and compute are decoupled. Unlike a traditional MPP warehouse where adding query capacity means adding storage nodes (and vice versa), Snowflake separates the two so that dozens of independent workloads can hit the same underlying data without contending for the same CPU. A good diagram doesn't just draw boxes for “Snowflake” — it shows which virtual warehouse handles which workload, how data lands and how it leaves, and where the cost controls live. This guide covers what to include and how to prompt an AI diagram generator to produce it.

The three-layer architecture — the defining fact to diagram

Every Snowflake architecture diagram should visually separate these three layers, because they scale, fail, and bill independently:

• Storage layer: Centralized, compressed, columnar storage sitting on the underlying cloud provider's object storage (S3, Azure Blob, or GCS depending on which cloud the account is deployed on). All data is stored once here regardless of which warehouse queries it — there is no data duplication per compute cluster. Show this as a single shared layer beneath every warehouse.
• Compute layer: One or more independently-scalable virtual warehouses. Each warehouse is its own isolated MPP cluster (T-shirt sized XS through 6XL) that reads from the shared storage layer but has no shared compute with any other warehouse. This is why an ETL warehouse melting down under load doesn't slow down the BI warehouse — they're physically separate clusters pointed at the same data.
• Cloud services layer: The stateless control plane — query parsing and optimization, transaction management, metadata and statistics, authentication/authorization, and infrastructure orchestration. This layer is fully managed and not something you size, but it's worth showing as a thin layer above compute since it's what routes and optimizes every query and enforces RBAC.

Draw storage at the bottom (shared, single instance), compute as multiple parallel boxes sitting on top of it (one per warehouse, isolated from each other), and cloud services as a horizontal band spanning across — that layout alone communicates 80% of what makes Snowflake's architecture different from Redshift or a self-managed cluster.

Core components to diagram

• Ingestion paths: Snowpipe for continuous/near-real-time loads (auto-ingest off cloud storage event notifications, or Snowpipe Streaming for row-level ingestion from Kafka), COPY INTO for scheduled batch loads, and external stages pointing at S3/Azure Blob/GCS buckets that hold raw files before or instead of loading. Annotate load frequency and file format (Parquet, JSON, CSV) on each path.
• Virtual warehouses sized per workload: The standard cost-governance pattern is separate warehouses for separate workloads — an ETL/loading warehouse, a BI/dashboard warehouse, and a data science/ad-hoc warehouse — rather than one shared warehouse for everything. This avoids a runaway analyst query starving a scheduled pipeline of compute. Diagram each warehouse with its size and which workload/team owns it.
• Database / schema / table hierarchy: Snowflake's namespace is database.schema.table. Show the raw/staging/marts schema split (often owned by different roles) and any shared or reader-account databases.
• Snowpark: Python, Java, and Scala compute pushed down to run inside Snowflake's compute layer rather than pulling data out to an external Spark cluster. Show Snowpark jobs as running on their own (or a dedicated) virtual warehouse, since they consume the same compute credits as SQL queries.
• Streams and Tasks: Streams capture row-level CDC (inserts/updates/deletes) against a table since it was last consumed; Tasks are scheduled or triggered SQL/Snowpark jobs, commonly chained after a Stream to build incremental pipelines entirely inside Snowflake without an external orchestrator. Diagram the Stream → Task → target-table chain explicitly if it replaces part of your ELT pipeline.
• Secure Data Sharing / Data Marketplace: Share live data across Snowflake accounts (or externally via reader accounts) without copying it — the consumer queries the provider's storage layer directly through a share object, paying only for their own compute. Diagram this as a distinct arrow type (share, not copy) between provider and consumer accounts.
• RBAC hierarchy: Roles (not users) own grants on warehouses, databases, and schemas, and roles inherit from other roles in a hierarchy (e.g., ANALYST → BI_READER). Show the role tree alongside — or overlaid on — the warehouse/schema diagram so it's clear which role can use which warehouse against which schema.

Multi-cluster warehouses: scaling concurrency, not just size

A single virtual warehouse can be configured as multi-cluster: instead of resizing the warehouse (scaling up), Snowflake automatically spins up additional clusters of the same size (scaling out) when queued queries indicate concurrency pressure, then scales back down as load drops. This is a distinct diagram element from warehouse sizing — label multi-cluster warehouses with their min/max cluster count (e.g., “BI_WH: Large, 1–4 clusters, auto-scale”) so it's clear the warehouse handles bursty concurrent BI traffic rather than a single heavy query.

Cost governance patterns worth diagramming

• Resource monitors: Credit quota objects attached to one or more warehouses (or account-wide) that trigger actions — notify, suspend, or suspend-immediately — at defined percentage thresholds (e.g., 75% notify, 100% suspend). Show which resource monitor governs which warehouse(s) and its threshold actions.
• Auto-suspend / auto-resume: Every warehouse should have an auto-suspend timeout (commonly 60–300 seconds) so idle compute stops billing, and auto-resume so the next query wakes it transparently. Annotate the suspend timeout per warehouse — it's one of the highest-leverage cost knobs in Snowflake.
• Warehouse-to-team cost attribution: Because each warehouse bills its own credit consumption independently, mapping one warehouse (or a small set) per team or workload gives clean chargeback/showback without needing query-level cost splitting. Diagram this as a direct line from team/workload → dedicated warehouse → credit usage, since it's the mechanism that makes Snowflake cost governance tractable at all.

Prompt examples for Snowflake architecture diagrams

Full modern data stack with Snowflake

Snowpipe streaming ingestion from Kafka

Secure Data Sharing between provider and consumers

Cost-governance diagram with resource monitors

Snowflake vs BigQuery vs Databricks vs Redshift

What to annotate on a Snowflake architecture diagram

• Warehouse size and auto-suspend setting: Every warehouse box should show its T-shirt size and idle-timeout seconds — these two settings drive most of the compute bill.
• Multi-cluster range: For warehouses handling concurrent BI/dashboard traffic, label the min/max cluster count and scaling policy (standard vs. economy).
• Resource monitor thresholds: Show which resource monitor applies to which warehouse(s), the credit quota, and the action at each threshold (notify, suspend, suspend immediately).
• RBAC role hierarchy: Annotate which role owns/uses each warehouse and schema, and how roles inherit from each other — this is what an auditor or security reviewer will look for first.
• Data sharing direction: Distinguish share (no-copy, live) arrows from ETL/copy arrows, and label provider vs. consumer accounts explicitly.
• Clustering keys: For very large tables, note any explicit clustering key used to keep micro-partition pruning effective — relevant for query performance, not just storage layout.
• Ingestion latency: Label whether each ingestion path is batch (COPY INTO, scheduled), micro-batch (Snowpipe auto-ingest), or streaming (Snowpipe Streaming) so downstream freshness expectations are clear.

Related guides: dbt architecture diagrams, modern data stack architecture, data mesh architecture, and data pipeline use cases.