Snowflake’s architecture differs from traditional databases in one key way: it separates storage and compute. While most databases tie these together, Snowflake keeps them independent.
Think of it like this: your data lives in shared storage, while compute resources (virtual warehouses) can spin up and down as needed. Multiple teams can work on the same data simultaneously without stepping on each other’s toes.
Let’s break down how Snowflake’s architecture actually works and what it means for your data platform.
The Three-Layer Architecture
Snowflake operates with three distinct layers that work independently while staying coordinated. Each layer handles specific tasks.
Layer One: Storage
This is where your data actually lives. When you load data into Snowflake, it reorganizes everything into an optimized, compressed, columnar format.
Your data sits in cloud storage – Amazon S3, Azure Blob Storage, or Google Cloud Storage depending on your cloud provider. Snowflake doesn’t maintain its own storage infrastructure. Instead, it leverages the scale and reliability of major cloud providers.
How Compression Works
Snowflake automatically compresses your data. You typically see 3x to 5x compression ratios. A 5 TB dataset might compress down to 1.2 TB, and you only pay for that 1.2 TB of storage. Snowflake stores the data in columnar format rather than rows, which speeds up analytical queries since you only read the columns you need.
Snowflake automatically divides your tables into small, immutable chunks called micro-partitions. Each one typically ranges from 50 to 500 MB when compressed. You never see these or manage them – Snowflake handles everything. This micro-partitioning enables features like Time Travel and zero-copy cloning.
Storage and Compute Separation
This storage layer operates completely separate from compute. Your data just sits there, compressed and organized, until a query needs it. You don’t pay for compute when you’re not using it.
I worked with a retail company that had 5 TB of raw data. After they loaded it into Snowflake, it compressed down to about 1.2 TB. They only paid for 1.2 TB of storage, and could run queries from multiple warehouses simultaneously. Multiple data science teams, BI analysts, and ETL jobs all hit the same data at the same time without performance degradation.
Layer Two: Query Processing (Virtual Warehouses)
Virtual warehouses handle the compute work. They operate as independent query engines that can spin up and down on demand.
Warehouse Sizing
Each warehouse comes sized like a t-shirt: X-Small, Small, Medium, Large, X-Large, and up to 6X-Large. Each size up doubles the compute power and doubles the cost. An X-Small warehouse costs 1 credit per hour, a Small costs 2 credits per hour, Medium costs 4 credits per hour. The pricing scales linearly.
Warehouses scale independently without affecting each other. You can run an X-Large warehouse for heavy ETL jobs while your BI users query the same tables on a Small warehouse. The ETL team gets the horsepower they need, the BI team gets responsive queries, and neither group slows down the other.
Multi-Cluster and Auto-Scaling
Warehouses also support multi-cluster mode, which automatically adds more clusters when query demand increases. If you suddenly have 50 people running reports simultaneously, Snowflake automatically spins up additional clusters to handle the load, then shuts them down when demand drops.
The auto-suspend and auto-resume features help with cost control. You set a timeout period (say, 10 minutes), and if the warehouse sits idle for that long, it automatically shuts down. When someone submits a query, it starts back up in 1 to 3 seconds. You only pay for compute when you actually use it.
Real-World Warehouse Configuration
A financial services client of mine runs three separate warehouses. They have ETL_WH set to Large for nightly data loads, which auto-suspends after 10 minutes. Their ANALYTICS_WH runs Medium-sized and stays on during business hours to power Tableau dashboards. And DATASCIENCE_WH runs X-Large but only spins up when their data scientists need to train ML models in Snowflake. They pay for what they use.
The cost math works out straightforward. A Medium warehouse running 8 hours per day costs about $480 per month (4 credits per hour times $2 per credit times 8 hours times 30 days).
Layer Three: Cloud Services
This layer coordinates everything and runs on Snowflake’s infrastructure. You don’t manage it, configure it, and typically don’t pay for it separately unless you use a large amount.
What the Services Layer Does
The services layer handles authentication and access control, manages user logins, roles, and permissions. It analyzes queries and creates optimized execution plans. It tracks metadata for all your objects – databases, schemas, tables, views, and their relationships. It ensures ACID compliance for transactions. It handles query result caching, so if someone runs the exact same query twice, the second time returns instant. And it manages security: encryption, key rotation, audit logging.
Services Layer Pricing
The services layer runs always-on but you typically don’t pay for it unless you consume more than 10% of your daily compute credits in services. For most users, Snowflake includes it in the base pricing.
How It All Works Together: Following a Query
Let’s trace what happens when you run a query. Say you write something like this:
SELECT customer_id, SUM(order_amount) as total
FROM orders
WHERE order_date >= '2025-01-01'
GROUP BY customer_id;Step 1: Authentication and Permissions
First, you submit the query through the web UI, a JDBC driver, or the API. The services layer checks your credentials and permissions. It verifies you have SELECT access on the orders table. If you don’t have the right permissions, the query stops here.
Step 2: Result Cache Check
Next, the services layer checks if this exact query result already exists in cache. If someone ran this identical query in the last 24 hours, Snowflake returns the cached result. No compute needed, no cost incurred. This result cache proves useful for dashboards that refresh periodically.
Step 3: Query Optimization
If no cached result exists, the services layer analyzes your query and creates an optimized execution plan. It examines the WHERE clause and figures out which micro-partitions contain data from 2025-01-01 onwards. It uses statistics from metadata to make these decisions without scanning actual data.
Step 4: Warehouse Assignment
The query routes to your specified virtual warehouse. If that warehouse is suspended, Snowflake auto-resumes it in 1 to 3 seconds. The warehouse gets compute resources allocated and prepares to execute the query.
Step 5: Data Retrieval
The warehouse pulls only the relevant micro-partitions from cloud storage. Thanks to partition pruning, it skips all the data that doesn’t match your WHERE clause. It retrieves the compressed, columnar data from S3, Azure Blob Storage, or GCS.
Step 6: Query Execution
The warehouse decompresses the data in memory, performs the filtering, aggregation, and grouping. It leverages multiple levels of caching – result cache for identical queries, local disk cache on the warehouse’s SSD for recently-used data, and optimized remote disk access for everything else.
Step 7: Results Delivery
Finally, the system delivers the results back to your client. The services layer caches the result for 24 hours so if anyone runs this exact query again, it returns instant. The entire process typically takes milliseconds for cached queries, or seconds for complex analytical queries across billions of rows.
The separation of storage and compute means Snowflake can optimize each layer independently. Storage optimization focuses on cost and durability. Compute optimization targets speed and concurrency. The services layer optimization handles coordination and metadata management.
If you want to dive deeper into making your queries faster, check out our guide on Snowflake query optimization.
Why This Architecture Matters
Independent Scaling
Traditional databases force you to choose: scale up by buying a bigger machine, or scale out by adding more machines and dealing with complexity. Snowflake lets you do both, independently. You can scale up by increasing your warehouse size for faster query performance. You can scale out by adding more warehouse clusters for higher concurrency. And you can scale storage separately without affecting compute costs.
Zero Contention Between Teams
Multiple teams can work on the same data simultaneously without performance impact. Your ETL jobs run on one warehouse, your data scientists use another, your BI dashboards hit a third, and your ad-hoc analysts use a fourth. Nobody waits. Each team gets dedicated compute resources but shares the same underlying data.
Straightforward Cost Model
Cost optimization becomes more straightforward. You only pay for storage you use (typically $23 to $40 per TB per month, depending on cloud provider) and compute when warehouses run (credits per hour based on size). You don’t need to over-provision for peak workloads.
A mid-size company with 10 TB of data stored pays around $300 per month for storage. If they run a Medium warehouse 8 hours per day, that adds another $480 per month in compute. Total monthly cost runs around $780 for a production data warehouse that multiple teams use.
Reduced Maintenance Burden
The maintenance burden drops significantly. You don’t manage server provisioning or patching. Snowflake handles weekly software upgrades automatically. You don’t need index tuning or table optimization. Backup and recovery happen automatically through Time Travel. Snowflake builds in high availability and disaster recovery.
Common Architecture Mistakes
Using One Warehouse for Everything
The most common mistake involves using one warehouse for everything. Your ETL jobs compete with user queries for resources, and everything slows down. The fix works simply: create separate warehouses for different workloads. Have an ETL_WH for data loading, a REPORTING_WH for BI tools, and an ADHOC_WH for analyst queries. Performance improves when you separate workloads.
Keeping Warehouses Always-On
Another frequent mistake involves keeping warehouses always-on. I’ve seen companies paying for compute 24/7 even when nobody uses it nights and weekends. Set appropriate auto-suspend timeouts instead. For ETL warehouses, use 5 minutes. For interactive warehouses, 10 minutes works well. For report warehouses that refresh periodically, 15 to 30 minutes makes sense. This can cut your compute bill significantly.
Wrong Warehouse Sizing
Wrong warehouse sizing also occurs commonly. Using an X-Large warehouse for simple queries wastes money. Using an X-Small for complex aggregations makes users wait. Start small and scale up based on actual performance. Simple queries work fine on X-Small to Small. Standard analytics need Medium. Heavy transformations want Large to X-Large. Massive batch jobs need 2X-Large or higher. Monitor query performance in the history tab and adjust.
Ignoring Result Caching
Not leveraging result caching leaves money on the table. If your dashboard refreshes hourly and runs the same queries, the result cache makes subsequent runs nearly free. Snowflake has three caching layers: result cache stores exact query results for 24 hours (free and instant), local disk cache stores recently-used data on warehouse SSD (fast), and remote disk cache accesses data from cloud storage (slower but optimized).
Making Architecture Decisions
How Many Warehouses?
When you design your Snowflake setup, think through a few key questions. How many warehouses do you need? Separate them by workload type like ETL, BI, and ad-hoc. Separate by department if you need cost tracking and chargebacks. Separate by priority to ensure production workloads don’t interfere with development. Most companies end up with 3 to 8 warehouses depending on complexity.
What Size Warehouses?
What size should each warehouse be? Start with Medium for most production workloads. Use query history to identify slow queries, then scale up if queries consistently take too long. Scale down if warehouse utilization runs low. You can change warehouse size without downtime or migration effort.
Multi-Cluster or Single?
Should you enable multi-cluster? Yes, if you have high concurrency needs where many users query simultaneously. Yes, if you have unpredictable spiky workloads. No, if you have predictable, steady workloads on dedicated warehouses. Multi-cluster costs more when extra clusters spin up, but it prevents users from waiting during peak times.
When evaluating whether Snowflake fits your organization, check out our build vs. buy framework for data products to make an informed decision.
Integration with Cloud Services
Snowflake’s architecture works well with cloud-native tools. On AWS, you get native integration with S3, Lambda, Glue, and SageMaker. On Azure, connection to Blob Storage, Data Factory, and Synapse. On GCP, it works with Cloud Storage, Dataflow, and BigQuery for migrations.
Since storage and compute operate separately, you can load data from S3 buckets without moving it around. Export results back to cloud storage for downstream processing. Trigger Snowflake queries from cloud functions. Connect ML platforms directly to Snowflake data.
If you’re interested in using Snowflake for data science work, explore Snowflake Snowpark for running Python and Scala code directly in your data warehouse.
What to Expect for Performance
Based on real-world experience across dozens of implementations, here’s what typical performance looks like.
Query Performance
Simple SELECT queries run in 10 to 100 milliseconds, often from cache. Complex aggregations on billions of rows take 5 to 30 seconds on a Medium warehouse. Heavy JOINs across large tables need 1 to 5 minutes on a Large warehouse. Full table scans on TB-scale data take 2 to 10 minutes on an X-Large warehouse. These reflect real-world numbers.
Data Loading Performance
For data loading, streaming ingestion has 5 to 10 minutes of latency. Bulk loading via COPY commands takes 1 to 5 minutes for gigabytes, 10 to 30 minutes for terabytes. Snowpipe for continuous loading provides near real-time with minute-level latency. Loading performance scales linearly with warehouse size.
Concurrency Limits
Concurrency depends on your warehouse configuration. A single warehouse handles 8 to 16 concurrent queries well. A multi-cluster warehouse scales to hundreds of concurrent users automatically. Using separate warehouses for different workloads gives you high concurrency since they don’t interfere with each other.
The Bottom Line
Snowflake’s multi-cluster shared data architecture changes how you approach data warehousing. The separation of storage and compute means you can scale each independently. Multiple teams work in parallel without interfering. You pay for what you use. Maintenance drops to minimal levels.
This architecture has made Snowflake a common choice for cloud data warehousing. The focus shifts from managing infrastructure to analyzing your data.
Now that you understand the architecture, if you’re just getting started, check out our companion guide on your first 30 days with Snowflake for a structured learning path. You can also explore Snowflake Cortex AI to see how Snowflake integrates AI capabilities into the platform.