Snowflake's Three-Layer Architecture, Explained
If there's one diagram you must know cold for the SnowPro Core (COF-C03) exam, it's Snowflake's three-layer architecture. Questions about it show up constantly, and understanding it makes the rest of the platform click into place.
Snowflake separates a data warehouse into three independent layers:
1. Cloud Services Layer
This is the "brain" that coordinates everything. It handles:
- Authentication and access control
- Query optimization and compilation
- Metadata management
- Transactions and infrastructure management
A classic exam question asks which layer is responsible for query optimization and metadata — the answer is Cloud Services, not Compute.
2. Compute Layer (Query Processing)
This is where queries actually run, using virtual warehouses — independent clusters of compute resources. Key ideas:
- Each virtual warehouse is isolated, so one workload can't slow another down.
- You can resize or spin up warehouses independently.
- You pay for compute only while a warehouse is running.
3. Database Storage Layer
Your data lives here, stored in Snowflake's optimized, compressed, columnar format on cloud object storage (S3, Azure Blob, or GCS). You never manage the files directly — Snowflake does.
Why the separation matters
Because storage and compute are decoupled, you can:
- Scale compute up or down without touching storage.
- Run many warehouses against the same data with no copies.
- Pay for storage and compute separately.
This separation is the single most important architectural idea in Snowflake — and the reason "elastic" and "multi-cluster" show up so often on the exam.
Quick exam tip
If a question mentions optimization, transactions, or metadata, the answer is almost always the Cloud Services layer. If it mentions running queries or virtual warehouses, it's the Compute layer. If it's about where data physically sits, it's Storage.
Want to test yourself? Try the free SnowPro Core questions in the study section, or get the CertiQ app for full mock exams and every domain.