The Snowflake AI Data Cloud solves a problem that bedevils traditional shared-disk and shared-nothing data warehouses: how to scale compute, storage, and concurrency independently without forcing each tenant to over-provision the entire stack. Legacy shared-disk systems concentrate contention on a single I/O subsystem, while shared-nothing MPP clusters tie storage to compute nodes, so scaling one means scaling the other and rebalancing data across nodes. Snowflake's multi-cluster shared data architecture decouples these three concerns into three named layers so that each layer can scale, fail, and bill independently.
When you choose Snowflake over an alternative such as a self-managed Postgres on a single virtual machine, or a Hadoop cluster with Hive on top, you are choosing this layered model. The trade-off is that you give up direct control over physical disk layout and node-level tuning in exchange for elastic compute, instant warehouse sizing, near-zero administrative overhead for storage, and a metadata layer that powers features such as Time Travel, zero-copy cloning, and result caching that are difficult to build on top of conventional engines.
Cloud Services layer
The Cloud Services layer is the brain of the account. It runs as a multi-tenant set of services managed entirely by Snowflake, with no per-account knobs to size or restart. The Cloud Services layer is responsible for authentication and access control, infrastructure management, metadata management, query parsing and optimization, result and metadata caching, transaction management, and the storage and execution of security policies. When a SQL statement arrives over a Snowflake driver, the Cloud Services layer authenticates the session, resolves the warehouse context, parses and plans the query, prunes partitions using metadata, and either returns a cached result or dispatches the plan to a virtual warehouse for execution.
Because the Cloud Services layer holds metadata such as the list of micro-partitions per table and their column min/max statistics, it is the layer that makes static metadata queries (such as SELECT COUNT(*) FROM customers when accurate row counts exist in metadata, or SELECT MAX(load_date) FROM orders) return without spinning up a warehouse. The Cloud Services layer also issues the query result cache that lets identical queries return prior results without re-executing.
Cloud Services consumption is billed only when daily usage exceeds 10% of daily warehouse credits. In a healthy account that runs warehouses regularly, Cloud Services credits are effectively free, because they fall under that 10% threshold every day. Workloads that hammer the Cloud Services layer with metadata-heavy operations (frequent SHOW commands, INFORMATION_SCHEMA scans, very short queries that never reach a warehouse) can push you over the threshold and incur Cloud Services charges.
📊 Limit: Cloud Services compute is free up to 10% of the daily warehouse compute credits consumed in the same account. Anything above 10% on a given day is billed at the standard credit rate.
Compute layer
The Compute layer is the set of virtual warehouses that execute SQL, Snowpark, and Cortex requests. A virtual warehouse is a managed cluster of compute nodes (in Snowflake terminology a "cluster of MPP servers") provisioned on demand. Each warehouse is independent: warehouses do not share cache with one another, do not share resources, and do not contend for each other's CPU or memory. This isolation is what lets ETL, BI, data science, and ad-hoc users coexist without one workload starving another.
Warehouses come in T-shirt sizes from X-Small (1 node, 1 credit per hour) up to 6X-Large (512 nodes, 512 credits per hour). Each size doubles both the node count and the credit-per-hour rate compared to the next smaller size. Snowflake bills warehouses per second after a 60-second minimum, so resuming and suspending a warehouse multiple times in an hour costs more than a single one-hour run only if your gaps are very short and your resume-on-demand pattern hits the 60-second floor repeatedly.
The Compute layer also hosts the Serverless Compute family. Serverless compute is provisioned and managed by Snowflake on dedicated compute resources outside of your virtual warehouses. Features such as Snowpipe, automatic clustering, materialized view maintenance, search optimization service builds, and Cortex serverless inference run on serverless compute. Serverless compute is billed in credits with its own rate, and it does not require you to run a warehouse for those operations.
Database Storage layer
The Database Storage layer holds all persistent table data in a columnar, compressed, immutable format that Snowflake calls a micro-partition. Storage sits on the underlying cloud provider's object store (Amazon S3, Azure Blob Storage, or Google Cloud Storage) and is fully managed by Snowflake. You never see a file path, you never tune block size, and you never run VACUUM or REINDEX. Storage is billed at a flat per-TB-per-month rate based on the average daily compressed volume across active storage, Time Travel storage, and Fail-safe storage.
Storage is decoupled from compute, so suspending or dropping a warehouse has no effect on the data itself. Storage is also shared across all warehouses in the account; a query running on WH_BI_S reads the same micro-partitions as a query running on WH_ETL_M. This is what makes zero-copy cloning possible: a CLONE operation copies only the metadata pointers to the existing micro-partitions, so the clone is created in seconds and consumes no incremental storage until either the original or the clone is modified.
Architecture diagram
The three layers communicate over Snowflake-managed network paths inside the chosen cloud region. The following flowchart shows the request flow from a client to storage.
Architecture Flow: Client Request Through the Three Layers
Compare and contrast the different Snowflake editions
Snowflake is sold in four editions: Standard, Enterprise, Business Critical, and Virtual Private Snowflake (VPS). Editions are an account-level setting, not a per-database setting. Each tier inherits everything from the tier below and adds capabilities.
Standard Edition is the entry tier. It includes the core platform: SQL, secure data sharing, Time Travel (limited to 1 day), automatic encryption, federated authentication, network policies, and standard support. Standard Edition is the right choice for a sandbox account, a low-risk analytics environment, or a small workload that does not need 90-day Time Travel or PHI/PII protections.
Enterprise Edition adds multi-cluster warehouses, extended Time Travel up to 90 days for permanent tables, materialized views, search optimization service, column-level security with dynamic data masking, object tagging, row access policies, and database failover and replication for business continuity. Enterprise is the typical choice for production analytics with multiple teams.
Business Critical Edition adds enhanced security and compliance: customer-managed keys via Tri-Secret Secure, support for PHI under HIPAA and HITRUST, PCI DSS support, AWS PrivateLink and Azure Private Link, Google Private Service Connect, and database failover with automated business continuity. Business Critical is the standard for regulated workloads such as healthcare or financial services.
Virtual Private Snowflake (VPS) runs the account in a dedicated Snowflake-managed metadata service and dedicated infrastructure isolated from other Snowflake accounts. VPS is the highest tier for organizations that require physical isolation. It includes all Business Critical features plus that isolation guarantee.
💡 Exam Trap: Time Travel maximum retention is 1 day on Standard Edition and 90 days on Enterprise and above for permanent tables. The default retention is 1 day regardless of edition. Transient and temporary tables max out at 1 day on every edition.
💡 Exam Trap: Multi-cluster warehouses (the ability to scale a warehouse OUT to multiple clusters for concurrency) require Enterprise Edition or higher. On Standard Edition, every warehouse runs as a single cluster regardless of how many concurrent users hit it.
⚠️ Anti-Pattern: Running a regulated healthcare workload on Standard or Enterprise Edition and assuming the standard encryption is sufficient for HIPAA compliance. HIPAA and PCI DSS support are gated to Business Critical Edition or higher. Encryption at rest and in transit are not enough on their own.
🎯 Scenario: A retail company runs an ETL pipeline that loads 5 TB of orders nightly and exposes them to fifty BI users between 8 AM and 6 PM. They observe queries queuing during the morning peak and have only Standard Edition. The fix is not to upsize the warehouse; doubling size doubles cost but does not address concurrency. The correct path is to move to Enterprise Edition so that the BI warehouse can be configured as a multi-cluster warehouse with min 1 and max 4 clusters under the Standard scaling policy, which spins up additional clusters when queries queue.
Decision Anchor: Choose Standard Edition when the workload is non-regulated, single-team, and tolerates 1-day Time Travel. Choose Enterprise Edition when you need multi-cluster warehouses, materialized views, search optimization, dynamic masking, or Time Travel beyond 1 day. Choose Business Critical when handling PHI, PCI, or PII data that requires HIPAA, HITRUST, or PCI DSS, or when you need PrivateLink. Choose VPS only when contractual isolation requirements mandate dedicated infrastructure.
Region and cloud-provider considerations
A Snowflake account is provisioned in one cloud (AWS, Azure, or GCP) and one region within that cloud. Cross-region and cross-cloud features such as replication, secure data sharing across regions, and failover require additional configuration and may have per-region availability constraints. Some features (such as the most recent Cortex models) roll out by region; treat regional feature availability as something to check in the official documentation before assuming a feature is present.
How the layers interact in practice
When a user runs SELECT customer_id, SUM(order_total) FROM orders WHERE order_date >= '2025-01-01' GROUP BY 1, the flow is:
- The driver opens a session with the Cloud Services layer using the configured authentication method.
- Cloud Services authenticates, resolves the active role, warehouse, database, and schema, and parses the SQL.
- The optimizer asks the metadata store which micro-partitions of
orderscould contain rows withorder_date >= '2025-01-01'using per-partition min/max statistics onorder_date. This is partition pruning. - If the same query was run within the last 24 hours by the same role with the same underlying data, Cloud Services serves the result from the query result cache and never invokes a warehouse.
- Otherwise, Cloud Services hands the plan to the active warehouse. The warehouse nodes read only the surviving micro-partitions from object storage, decompress them, apply the filter and aggregation, and stream results back through Cloud Services to the client.
- The result is cached for 24 hours and the warehouse goes back to its idle pool or suspends after the configured auto-suspend timeout.
-- Identify whether a query was served from the result cache
SELECT query_id,
execution_status,
warehouse_name,
warehouse_size,
bytes_scanned,
percentage_scanned_from_cache,
total_elapsed_time
FROM TABLE(INFORMATION_SCHEMA.QUERY_HISTORY())
ORDER BY start_time DESC
LIMIT 20;
💡 Exam Trap: The query result cache lives in the Cloud Services layer, not in the warehouse. Suspending or resizing a warehouse does not invalidate the result cache. The cache is invalidated when the underlying micro-partitions change or after 24 hours of inactivity (with rolling refresh up to 31 days when reused).
# Check edition for the current account using SnowSQL or the Snowflake CLI
snow sql -q "SELECT CURRENT_REGION(), CURRENT_ACCOUNT(), SYSTEM\$GET_EDITION();"
The architecture description above is the foundation for every other concept in this chapter. Warehouses, storage, governance, and AI features are all surfaces over the same three layers, and exam questions frequently test whether you can attribute a behavior to the correct layer.