Snowflake Architecture Layers: How Storage, Compute, and Cloud Services Actually Separate
Country Manager, Sweden
AI, DevOps, Security, and Cloud Solutioning. 12+ years leading enterprise cloud transformation across Scandinavia
Snowflake's data warehouse architecture separates three layers: a database storage layer (immutable micro-partitions in cloud object storage), a compute layer of virtual warehouses that read and write that storage, and a cloud services layer that handles authentication, query optimization, metadata, and security. Each layer scales independently. The separation is what makes zero-copy cloning, instant scale-up, and per-second billing possible — features that competing platforms had to bolt on after the fact.
Key Takeaways
- Snowflake is a hybrid shared-disk + shared-nothing architecture: shared-disk because all virtual warehouses read the same storage, shared-nothing because each warehouse processes queries on its own dedicated compute.
- Storage uses immutable, columnar micro-partitions (~16 MB compressed each). Files are never updated in place — DML operations write new partitions and mark old ones stale.
- The compute layer is virtual warehouses — independent MPP clusters that resize, suspend, and clone without touching storage.
- The cloud services layer holds metadata (table schemas, statistics, privileges, query history) and is the layer where security, transactions, and query planning live. It runs on dedicated Snowflake-managed compute, billed at 10% of warehouse credits when it exceeds the included free quota.
- Zero-copy cloning, time-travel, and Secure Data Sharing are direct consequences of the storage layer's immutability — not separate features built on top.
The Three Layers
1. Database Storage Layer
All persistent data lives in cloud object storage — S3 on AWS, Azure Blob on Azure, Google Cloud Storage on GCP. Snowflake doesn't expose the underlying buckets; everything goes through the SQL layer. Files are organised as micro-partitions, the fundamental unit of physical storage:
- Each micro-partition is 50–500 MB uncompressed (typically 16 MB compressed) and contains rows of one table.
- Storage is columnar within a partition — each column is stored contiguously, which is what makes column pruning effective.
- Partitions are immutable. UPDATE / DELETE operations write a new micro-partition with the changed rows and mark the old one as stale. The old version remains for time-travel until the retention window passes, then for fail-safe (Snowflake-controlled) for an additional 7 days.
- Metadata about every micro-partition — min/max value per column, distinct count, null count, total size — lives in the cloud services layer and is used for partition pruning at query time.
This immutability is load-bearing for several Snowflake features: time-travel works because old partitions still exist, zero-copy clones work because a clone just creates a metadata pointer to existing partitions, and Secure Data Sharing works because shared databases reference the source's partitions directly without copying bytes.
2. Compute Layer (Virtual Warehouses)
A virtual warehouse is an independent MPP compute cluster — typically a small fleet of EC2 / Azure VM / GCE instances managed by Snowflake. Each warehouse runs one query at a time on its compute (with concurrency depending on size and scaling policy). When a warehouse needs data, it reads micro-partitions from the shared storage layer, caches them locally on its SSDs (the warehouse-local cache), and processes them.
The architecture is hybrid:
- Shared-disk — all warehouses see the same storage, so two warehouses can query the same table simultaneously without contention. Querying patterns dictate compute, not data placement.
- Shared-nothing — within a warehouse, each compute node handles a partition of the work, and nodes don't share memory. Joins, aggregations, and sorts shuffle data over the warehouse's internal network.
Warehouse sizes (XS through 6XL) double in compute and roughly double in cost per tier. Multi-cluster warehouses spawn additional clusters when query queue depth crosses a threshold — the SCALING_POLICY governs how aggressively. A warehouse can suspend (zero compute cost), resize on the fly (no data movement, since storage is shared), and clone instantly (the cloned warehouse points at the same storage on day one).
3. Cloud Services Layer
The cloud services layer is the orchestrator. It handles:
- Authentication and authorization — which user/role can do what, including session management and SSO/SCIM integration.
- Query parsing and optimization — taking SQL, building an execution plan, deciding which warehouse runs it, and which micro-partitions to read.
- Metadata management — table schemas, micro-partition statistics, materialized view definitions, masking policies, row access policies.
- Transaction management — Snowflake supports ACID transactions at the database level via metadata versioning rather than locks.
- Security and governance — column-level encryption keys, network policies, audit log generation.
Cloud services runs on Snowflake-managed compute that customers don't size or see directly. Billing is opaque except for the 10% rule: if cloud services credits exceed 10% of total warehouse credits in a given day, the excess is billed; below 10% it's included. This rule is rarely a problem for typical workloads but can bite organisations doing heavy metadata-only operations (frequent schema changes, lots of zero-copy clone creation, or pure-metadata queries).
Need expert help with snowflake architecture layers?
Our cloud architects can help you with snowflake architecture layers — from strategy to implementation. Book a free 30-minute advisory call with no obligation.
What the Separation Enables
Independent Scaling
Storage scales linearly with data volume; compute scales with workload concurrency and query complexity. The two are decoupled. A 100 TB analytics warehouse running batch ETL once a day costs the same on storage as one running interactive queries all day — but the compute side looks completely different. Traditional shared-everything (Teradata, Oracle Exadata) tied storage and compute together because they ran on the same hardware. Snowflake's decoupling broke that constraint and is what made cloud-native data warehousing economically different.
Zero-Copy Cloning
A clone of a 5 TB table doesn't copy any bytes. The cloud services layer creates a metadata entry that points at the source's existing micro-partitions. Both the source and the clone reference the same partitions until one of them changes. When a write happens, only the changed micro-partitions are written separately. Storage cost only grows as divergence grows.
This makes dev/staging environments practical at scale. Cloning the production database for a development branch is metadata-only — instant and free until you actually modify data on the clone.
Time-Travel and Fail-Safe
Time-travel queries (AT (TIMESTAMP => ...) or BEFORE (STATEMENT => ...)) read old versions of micro-partitions that haven't aged out yet. The retention window is per-table (default 1 day, configurable up to 90 days for Enterprise edition). Fail-safe is an additional 7-day Snowflake-controlled retention after time-travel expires; it's only accessible via Snowflake support, not via SQL. Both are direct consequences of the storage layer's immutability — there's no separate "versioning" subsystem.
Secure Data Sharing
Sharing a database with another Snowflake account doesn't copy data. The provider account creates a Share object pointing at specific tables / views; the consumer account creates a database from the Share. Queries from the consumer's compute read the provider's micro-partitions directly, with the cloud services layer enforcing the access policy. The shared data is always live — no replication, no scheduled refresh.
Comparison to OLAP / OLTP and Other Architectures
| Property | Snowflake | Traditional OLAP (Oracle Exadata, Teradata) | OLTP (PostgreSQL, MySQL) |
|---|---|---|---|
| Workload | Analytical / OLAP | Analytical / OLAP | Transactional / OLTP |
| Storage layout | Columnar, immutable micro-partitions on object storage | Columnar/row, on attached disk | Row-based, on attached disk |
| Compute / storage coupling | Decoupled — storage shared across warehouses | Coupled — compute owns its disks | Coupled — compute owns its disks |
| Concurrency model | Multiple warehouses query the same data without contention | Single shared cluster with workload management | Row-locking, MVCC |
| Scaling | Resize warehouse instantly; storage grows separately | Add nodes / re-shard data | Vertical scaling; read replicas |
| ACID transactions | Yes, via metadata versioning | Yes | Yes |
Snowflake is OLAP, not OLTP. The micro-partition model and the 60-second compute floor make point-lookup OLTP workloads (find user 12345, update one field) economically unworkable — it's possible to run them, just expensive per row. The right tool for OLTP remains a row-based transactional database (PostgreSQL, Aurora, etc.). Snowflake handles the analytical layer that consumes OLTP data downstream.
Practical Implications for Architecture Decisions
- Workload isolation — give each major workload its own warehouse. A heavy ETL job running on the same warehouse as analyst queries will queue or scale, both bad outcomes. Cost-attribution by warehouse is also clean only when warehouses match workloads.
- Clustering keys aren't free — automatic clustering re-organises micro-partitions to align with a chosen key, but it's billed in serverless credits. The break-even is the cost of repeated full-partition scans without clustering vs the cost of maintenance with clustering. Most tables don't need it.
- Time-travel cost — extending time-travel to 90 days on a fast-changing table multiplies storage cost. Set the retention per-table to match the recovery window the business actually needs.
- Cloud services credits — if your workload is metadata-heavy (frequent DDL, lots of zero-copy clone creation, heavy SHOW commands), watch the 10% threshold. Most workloads stay below it.
How Opsio Approaches Snowflake Architecture
Opsio runs data analytics platforms on Snowflake for clients across the EU and India. The recurring architecture decisions:
- One account, multiple databases with role-based isolation — simpler than multi-account architectures and fits Snowflake's RBAC model cleanly.
- Per-workload warehouse separation — at minimum: ELT load warehouse, transform warehouse, BI/analyst warehouse, dev warehouse. This gives clean cost attribution and keeps interactive queries off the path of long-running ETL.
- Time-travel scoped per table — 7 days default for facts, 1 day for staging, 30+ days only for tables under regulatory recovery requirements.
- Resource Monitors deployed account-wide from day one — the single most-effective cost-control feature, set up before any optimization work.
Frequently Asked Questions
What is Snowflake data warehouse architecture?
A three-layer cloud-native architecture separating database storage (immutable columnar micro-partitions on cloud object storage), compute (virtual warehouses — independent MPP clusters), and cloud services (metadata, query optimization, security, transactions). The three layers scale independently, which is what enables features like instant warehouse resize, zero-copy cloning, time-travel, and Secure Data Sharing.
What are the 5 types of data warehouse architecture?
The classical typology is single-tier (data + reporting on one system, generally avoided), two-tier (data warehouse + clients, simple but coupled), three-tier (data sources, data warehouse, OLAP/BI tools — the traditional Inmon/Kimball model), data lakehouse (storage in object stores + on-demand compute, of which Snowflake is one example), and cloud-native data warehouse (Snowflake's three-layer model with full storage/compute decoupling). The boundaries between the last two have blurred since 2020.
Is Snowflake an OLAP or OLTP system?
OLAP. The columnar micro-partition storage, the 60-second warehouse minimum, and the optimizer's cost model are all designed for analytical workloads — large scans, aggregations, joins, and bulk inserts. Point-lookup OLTP workloads work mechanically but are uneconomic. The right pattern is OLTP databases for transactional systems, with data flowing into Snowflake for analytics.
Does Snowflake have a data warehouse, or is it the data warehouse?
Snowflake is the data warehouse. The platform combines the storage, compute, and metadata layers traditionally provided by separate components. The term "virtual warehouse" inside Snowflake refers to a compute cluster, not a separate data warehouse — there's only one underlying database storage layer per account, with multiple warehouses reading and writing it.
How does Snowflake handle ACID transactions if storage is immutable?
Snowflake supports ACID transactions via metadata versioning in the cloud services layer. When a transaction starts, the cloud services layer captures the current set of valid micro-partitions for each table. DML operations within the transaction write new micro-partitions but don't make them visible. On commit, the metadata atomically swaps to point at the new partitions; on rollback, the new partitions are discarded. Concurrent transactions see consistent snapshots without locks because each one sees its own metadata view.
About the Author
Country Manager, Sweden at Opsio
AI, DevOps, Security, and Cloud Solutioning. 12+ years leading enterprise cloud transformation across Scandinavia
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.