How Snowflake separates storage from compute, and what that separation means in practice.
Snowflake is built from three layers that scale independently: a storage layer of immutable compressed micro-partitions in cloud object storage, a compute layer of virtual warehouses that read those partitions, and a cloud services layer that holds metadata, optimizes queries, enforces security, and coordinates transactions. Almost every operational behaviour, from cost to concurrency to time travel, follows from that split.
Storage is shared and billed per terabyte; compute is billed per second while a warehouse runs; the services layer is mostly included. Because partitions are immutable, updates write new partitions and the old ones remain available for Time Travel and Fail-safe until retention expires, and zero-copy clones simply point at existing partitions.
| Question | Page |
|---|---|
| How do I run Snowflake well in production (warehouses, security, cost, interview topics)? | Snowflake Production Guide |
| Permanent, transient, temporary, external, dynamic, or hybrid table: which one? | Snowflake Table Types |
Read the production guide first for the operating model, then the table-types page when designing a schema, since table type determines retention, recovery, and storage cost.