Snowflake Architecture Demystified
When studying for the SnowPro Core Certification, one of the areas that comes up again and again is Snowflake’s architecture. On the surface it looks simple, compute, storage, and services. But the exam expects you to know not just what each layer does, but also why this layered design makes Snowflake different.
In this article
The Three-Layer Design:
- Storage Layer
- Query Processing Layer
- Cloud Service Layer
Also related to:
- Caching in Snowflake
- Snowflake’s Hybrid Architecture
1. Storage Layer
-
All data is stored in an internal, columnar file format.
-
Data is divided into micro-partitions (small, immutable chunks, typically 50–500MB uncompressed, max 16MB compressed).
-
Snowflake automatically handles partitioning — you don’t manage files directly unlike tools like redshift.
-
Data is encrypted, compressed, and optimised by default.
-
Metadata about each micro-partition (value ranges, NULL counts, distinct counts) is stored in the services layer and is queryable without using a warehouse.
2. Query Processing Layer
- Compute resources come in the form of Virtual Warehouses.
- Each warehouse is an independent MPP cluster (Massively Parallel Processing) — meaning it doesn’t share compute resources with other warehouses.
- Warehouses can scale vertically (resize XS → 4XL) or horizontally (multi-cluster warehouses).
- Warehouses can be paused (auto-suspend) and resumed (auto-resume) to save costs.
Note: Resizing a warehouse affects only new queries; running queries are unaffected.
3. Cloud Services Layer
-
- This is Snowflake’s “command centre.”
-
It coordinates query compilation, optimisation, and execution.
-
Responsibilities include:
-
Authentication & Access Control
-
Metadata Management
-
Infrastructure Management
-
Query Parsing & Optimisation
-
-
This layer is shared across Snowflake accounts (except in VPS edition, where it’s isolated).
-
Customers cannot see or manage the internals of this layer.
Note: The result cache and metadata cache live here