Introduction
Snowflake architecture separates database storage, compute, and cloud services while presenting them as one managed platform. This separation is the foundation for workload isolation, elastic compute, centralized metadata, and shared access to persisted data. Understanding the responsibility of each layer is more useful than memorizing a three-box diagram because operational symptoms usually belong to one layer or to the boundary between layers.
Architecture Overview
Snowflake combines characteristics of shared-disk and shared-nothing systems. Persisted data is held in a central cloud-storage repository that multiple compute clusters can access. Query processing uses massively parallel processing inside independent virtual warehouses. Snowflake-managed cloud services coordinate requests, security, metadata, and optimization.
The service is hosted on supported public cloud infrastructure and managed by Snowflake. Customers select and configure logical Snowflake resources, but they do not install Snowflake on local servers or manage its underlying storage nodes.
Core Components
Database storage
When data is loaded into a Snowflake table, Snowflake reorganizes it into an optimized, compressed, columnar format and stores it in cloud storage. Snowflake manages the file organization, compression, metadata, and statistics. Standard Snowflake tables are divided automatically into micro-partitions.
Storage is persistent and independent of a virtual warehouse's lifecycle. Suspending a warehouse stops its compute consumption after applicable billing behavior; it does not delete table data. Different warehouses can read the same persisted data subject to transaction consistency and access control.
Snowflake also supports table types with different storage models, including Apache Iceberg™ tables that use customer-managed external cloud storage and hybrid tables designed for low-latency transactional access. These are not interchangeable with standard Snowflake tables, so feature support must be verified per table type.
Compute
A virtual warehouse is a cluster of compute resources. It executes SQL statements and supports other documented workloads. Warehouses are independent: one warehouse does not share compute resources with another. This allows teams to isolate workloads such as ingestion, business intelligence, and transformation while accessing common data.
Warehouse size changes the compute available within a cluster. Multi-cluster warehouses address concurrency by adding clusters within configured limits, whereas resizing a warehouse changes the resources per cluster. These actions solve different constraints and have different cost effects.
Cloud services
The cloud services layer coordinates the platform. Its documented responsibilities include security, authentication, access control, metadata management, query parsing and optimization, infrastructure coordination, and regulatory-compliance services.
When a client submits SQL, cloud services authenticate the session, evaluate access, parse the statement, and produce an execution plan. A selected virtual warehouse performs the data-processing work. Metadata helps the optimizer identify which micro-partitions and columns are relevant, reducing unnecessary scans when pruning conditions are effective.
How the Layers Work Together
Consider a dashboard query:
- A driver establishes a session with the Snowflake account.
- Cloud services authenticate the identity and determine the active role and session context.
- Access control is evaluated for the warehouse and referenced objects.
- The SQL is parsed and optimized using object and micro-partition metadata.
- The virtual warehouse executes the plan and reads required persisted data.
- Results are returned to the client; eligible persisted query results may be reused according to documented cache behavior.
This sequence helps isolate failures. An authentication error occurs before warehouse execution. A warehouse-usage privilege error is an authorization issue. Queueing points to compute availability or concurrency. Excessive remote scanning may indicate ineffective pruning or a data-organization problem.
Design Considerations
Isolate workloads deliberately
Separate warehouses can protect interactive analytics from long-running transformation or ingestion workloads. Isolation is not free: each active warehouse can consume credits, and redundant compute may reduce cache locality. Define the isolation goal before creating additional warehouses.
Align compute changes to evidence
Scale up when a workload needs more resources per query and the execution profile supports that diagnosis. Scale out with multi-cluster behavior when concurrency and queueing are the primary constraints. Confirm edition availability and cost before enabling features.
Preserve security boundaries
Access to a database object and permission to use a warehouse are separate privileges. Grant both through functional roles rather than relying on a highly privileged administrator role for routine sessions.
Common Mistakes
- Describing a virtual warehouse as permanent table storage.
- Assuming larger compute always improves a query whose main issue is pruning or blocking.
- Confusing cloud services with customer-configured warehouses.
- Ignoring the active role or current warehouse when diagnosing a request.
- Applying standard-table behavior to Iceberg or hybrid tables without checking support boundaries.
Certification Relevance
The COF-C03 page explicitly includes use of the Snowflake AI Data Cloud architecture. Practical readiness means being able to assign objects and symptoms to the correct layer, trace the request path, and explain why storage and compute can scale independently.
Authoritative Sources
- Snowflake key concepts and architecture
- Overview of warehouses
- Understanding Snowflake table structures
Conclusion
Snowflake's three-layer architecture is an operational model, not only a conceptual diagram. Persistent storage holds managed data, independent warehouses execute workloads, and cloud services coordinate security, metadata, and optimization. Using that model makes design and troubleshooting decisions more precise.

