Snowflake uses a multi-cluster shared-data architecture that differs from both traditional shared-disk and shared-nothing designs. Storage, compute, and cloud services are fully decoupled, and each layer scales independently. This article walks through the role of each layer, micro-partitions, the cache hierarchy, and the Cloud Services billing rule — the exam-relevant essentials plus what matters in production.
Snowflake's architecture is built from three layers. Each layer scales and fails over independently, freeing users from infrastructure management so they can focus on analytics.
┌─────────────────────────────────────────────┐
│ Cloud Services Layer │
│ Auth / Access Control / Query Optimization │
│ Metadata Management / Transactions │
├─────────────────────────────────────────────┤
│ Compute Layer (Virtual Warehouses) │
│ WH-1 (XS) │ WH-2 (L) │ WH-3 (XL) │
│ Independent clusters, isolated from each │
├─────────────────────────────────────────────┤
│ Storage Layer │
│ Cloud Object Storage (S3 / Azure Blob / GCS)│
│ Micro-partitions (columnar, compressed) │
└─────────────────────────────────────────────┘
Data is stored on cloud-provider object storage (AWS S3, Azure Blob Storage, Google Cloud Storage) in a columnar format. Users never interact with storage directly — Snowflake handles all data management automatically.
Table data is automatically split into units called micro-partitions.
| Property | Detail |
|---|---|
| Size | 50-500 MB compressed (uncompressed equivalent is several hundred MB) |
| Format | Columnar storage format |
| Management | Snowflake handles splitting and reorganization automatically (no user action required) |
| Metadata | Per-partition min/max, NULL count, and distinct count metadata for every column |
| Pruning | WHERE clauses are matched against metadata so irrelevant partitions are skipped |
| Immutability | Once created, partitions are immutable (INSERT/UPDATE/DELETE create new partitions) |
Micro-partition immutability is what enables Time Travel (point-in-time queries) and Fail-safe (disaster recovery). When you run UPDATE, the affected partition is recreated as a new version, and the previous version is retained for the Time Travel window.
Virtual Warehouses handle query execution. Each warehouse is an independent compute cluster — workloads in one warehouse don't impact others.
| Size | Credits/Hour | Typical Use Case |
|---|---|---|
| X-Small | 1 | Development, testing, light queries |
| Small | 2 | Small dashboards |
| Medium | 4 | Medium ETL and BI workloads |
| Large | 8 | Large batch processing |
| X-Large | 16 | Full scans on TB-scale tables |
| 2XL〜6XL | 32〜512 | Very large data processing |
Warehouses support multi-cluster scaling, automatically adding clusters as concurrent query count grows. Auto-suspend stops idle warehouses, and auto-resume starts them again on the next query.
The 'brain' of Snowflake. Users never see this layer directly, but it handles these critical responsibilities:
| Item | Value |
|---|---|
| Billing threshold | 10% of daily warehouse credit consumption |
| What's billed | Only the portion exceeding 10% |
| How to check | ACCOUNT_USAGE.METERING_HISTORY view |
| Common over-threshold cases | Heavy SHOW/DESCRIBE usage, Snowpipe notification processing, high-volume COPY INTO |
Example: if warehouses consume 200 credits in a day, the Cloud Services threshold is 20 credits. If Cloud Services consumed 25 credits, only 25 - 20 = 5 credits are billed on top.
Snowflake has three caches that improve query performance and reduce cost.
| Cache type | Location | Lifetime | Hit conditions | Cost |
|---|---|---|---|---|
| Result Cache | Cloud Services Layer | 24 hours (extended on reuse) | Same query, same role, no data change | No warehouse used (zero credits) |
| Metadata Cache | Cloud Services Layer | Always-on | Aggregation queries like COUNT/MIN/MAX | No warehouse used (zero credits) |
| Warehouse Cache (Local Disk Cache) | Warehouse SSD | While warehouse is running | Same warehouse accessing same table | Included in warehouse cost |
Result Cache is the most cost-effective — it returns results without starting a warehouse. It shines for repeated identical queries like scheduled BI dashboard refreshes. But Result Cache is invalidated as soon as DML runs on the underlying table.
| Feature | Standard | Enterprise | Business Critical | VPS |
|---|---|---|---|---|
| Multi-cluster warehouses | - | Yes | Yes | Yes |
| Time Travel (up to 90 days) | 1 day only | Up to 90 days | Up to 90 days | Up to 90 days |
| Materialized views | - | Yes | Yes | Yes |
| Search Optimization Service | - | Yes | Yes | Yes |
| Tri-Secret Secure | - | - | Yes | Yes |
| AWS PrivateLink / Azure Private Link | - | - | Yes | Yes |
| Dedicated metadata store | - | - | - | Yes |
On the SnowPro Core exam, the Architecture domain is about 25% of the test — the single biggest area. These are the points you should expect to be tested on:
SnowPro Core
問題 1
Which statement about Snowflake's Result Cache is correct?
正解: B
Result Cache lives in the Cloud Services Layer for 24 hours. It hits when the query text and role match and no DML has changed the underlying tables, returning results without starting a warehouse. Option A actually describes Warehouse Cache (Local Disk Cache).
What are the benefits of separating storage and compute in Snowflake's three-layer architecture?
Storage and compute scale independently, so you can grow only storage as data volume rises, or scale warehouses up and down based on query load. You don't carry idle capacity the way a traditional on-prem DWH forces you to, and cost efficiency improves dramatically. A second major benefit: multiple warehouses can access the same data concurrently without lock contention.
How is Cloud Services Layer billing calculated?
Cloud Services credits are billed only for usage that exceeds 10% of daily warehouse credit consumption (the 10% adjustment rule). For example, if warehouses consume 100 credits and Cloud Services consume 15, only 15 - 10 = 5 credits are billed. The design effectively makes core services like authentication, metadata management, and query optimization free.
How do micro-partitions relate to clustering keys?
Snowflake automatically splits data into 50-500 MB compressed micro-partitions and stores per-partition min/max metadata. When you set a clustering key, partitions are reorganized (reclustered) by the specified columns, which improves pruning efficiency. Reclustering consumes credits, so the typical recommendation is to consider clustering keys only when tables are larger than 1 TB and frequently filter by a specific column.
Practice with certification-focused question sets
Try free practice questionsNicheeLab Editorial Team
NicheeLab editorial team focused on data engineering and cloud certification learning. Content is structured around practical study needs and official exam domains.
Snowflake Certifications: All 11 Exams Explained (2026)
Every SnowPro certification — Associate, Core, Specialty, Ad...
Snowflake Exam Difficulty Ranking: All 11 Certs Compared (2026)
All 11 SnowPro exams ranked by difficulty with study-time es...
Snowflake Study Guide: Fastest Pass Route by Exam (2026)
How to pass SnowPro certifications efficiently — official ma...
SnowPro Core (COF-C03): Complete Exam Guide (2026)
Pass the SnowPro Core exam — six domains, scope, sample ques...
SnowPro Associate Platform (SOL-C01): Complete Guide (2026)
The entry-level SnowPro Associate exam — scope, weighting, s...