Snowflake Architecture

Snowflake's architecture consists of three logically separate but tightly integrated layers: a centralized storage layer, an elastic multi-cluster compute layer made of virtual warehouses, and a cloud services layer that coordinates everything from authentication to query optimization. This hybrid design borrows the best of shared-disk architectures (single copy of data) and shared-nothing architectures (independent compute nodes), which is why Snowflake documentation calls it a 'multi-cluster, shared data' architecture.

When data is loaded into Snowflake, it is automatically reorganized into compressed, columnar micro-partitions — typically 50 to 500 MB of uncompressed data each — and stored in the cloud provider's object storage (such as Amazon S3). Snowflake maintains rich metadata about each micro-partition, including min/max values per column, which lets the query optimizer prune irrelevant partitions instantly without scanning them, a technique called partition pruning.

A virtual warehouse is a cluster of compute resources — CPU, memory, and temporary storage — that you spin up to run queries, sized from X-Small to 6X-Large, with each size roughly doubling the compute of the one below it. Because warehouses read the same underlying storage, you can run a 'LOADING_WH' for ETL and a completely separate 'BI_WH' for dashboard queries against the same tables at the same time, and either warehouse can auto-suspend after idling to stop billing.

The cloud services layer is Snowflake's own managed fleet of servers that handles authentication, access control, the query parser and optimizer, infrastructure management, and metadata — all without you provisioning anything. This is also where result caching lives: if you rerun an identical query within 24 hours and the underlying data hasn't changed, Snowflake can return the cached result directly from this layer without spinning up any warehouse compute at all.