Platform Architecture and Cloud Services

Understand what you are and are not responsible for

Before you tune anything in Snowflake, you need to know which side of the line each task sits on. Snowflake is a self-managed service that combines data storage, processing, and analytics in one platform, and that service model decides what a customer never has to do.

Customers do not select, install, configure, or manage physical or virtual hardware for the service. Snowflake handles ongoing maintenance, management, upgrades, tuning, software updates, and infrastructure.

The service model removes infrastructure work, not workload decisions. You still choose what to run and where to run it.

The service uses public-cloud infrastructure for virtual compute instances and persistent data storage. That choice has a hard consequence for deployment planning: Snowflake cannot be installed and run locally or on private-cloud infrastructure, whether that infrastructure is on-premises or hosted.

"Hosted" does not create an exception. A private cloud that someone else operates is still a private cloud, so the answer to "can we install it in our own hosted private cloud?" is no.

Two requests that sound similar therefore land very differently:

• "Keep our persistent table data on public-cloud storage and let Snowflake patch it." — this is exactly the documented model.
• "Install the Snowflake engine inside our hosted private cloud." — this conflicts with the service model, and no configuration setting changes that.

See why the architecture is a hybrid

Traditional systems force a trade. Shared-disk designs keep one copy of the data that every node can read, which is simple to manage but concentrates work. Shared-nothing designs spread data across nodes for parallel speed, but every node then owns a slice, which complicates management.

Snowflake combines characteristics of both. Like a shared-disk system, it keeps persisted data in a central repository that all compute nodes can access. Like a shared-nothing system, it processes queries with massively parallel processing compute clusters whose nodes keep a portion of the data set locally.

This design joins the data-management simplicity of shared disk with the performance and scale-out benefits of shared nothing.

The word "locally" is where learners usually slip. A node holding a portion of the data set during massively parallel processing is not the same thing as a cluster owning a permanent private copy of the table.

Keep the two ideas separate:

• Persisted data lives once, centrally, and every compute node can reach it.
• Processing data is distributed across the nodes of an MPP cluster while a query runs.

That is precisely why the hybrid works: management stays centralized while execution stays parallel.

Map the three layers

The architecture has three key layers: database storage, compute, and cloud services. Each one owns a different question, and most exam scenarios are solved by deciding which question is being asked.

Networking, client drivers, user hardware, and local storage are not architectural layers. When an option offers those instead, it is describing the surroundings of the platform rather than its structure.

Let database storage own the physical detail

When data is loaded into a Snowflake table, Snowflake reorganizes it into an optimized, compressed, columnar format in cloud storage. From that point on, the physical representation is the platform's responsibility, not the customer's.

Snowflake manages storage organization, file size, structure, compression, metadata, and statistics. Snowflake tables are also automatically divided into contiguous storage units called micro-partitions.

So a team that asks to set file size, compression, and internal organization by hand for every table is asking for work that the platform already performs. The optimized representation persists in cloud storage; it is not something each warehouse configures, each client driver negotiates, or each query rebuilds before it runs.

Storage owns representation only. It does not authenticate anybody and it does not execute anything.

Reading the table down this axis settles most questions quickly: anything about identity belongs to cloud services, anything about execution resources belongs to compute, and everything about how bytes are laid out belongs to storage.

Use compute for isolation

A virtual warehouse is a cluster of compute resources that processes SQL statements and can run Java, Python, and Scala code through Snowpark. It is the layer that actually executes work.

Its defining property is independence: each virtual warehouse is an independent compute cluster that does not share compute resources with other virtual warehouses. Consequently, the workload on one virtual warehouse does not affect the performance of another virtual warehouse.

That single property answers a whole family of design questions. If two teams query the same persisted tables but one team's heavy workload must not slow the other down, give each team its own warehouse. They keep reading the same central data, and only their compute is separated.

Notice what the isolation is not. Warehouses do not each own a private persistent copy of the tables, they do not merge into one pool that is divided by priority, and they do not start sharing nodes because they happen to read the same table.

Let cloud services coordinate the request

The cloud services layer coordinates activity across Snowflake and ties the components together for requests from sign-in through query dispatch. It is the layer you never provision and always use.

It manages security, authentication, access control, infrastructure coordination, metadata, query parsing, query optimization, and regulatory compliance. Like the rest of the platform, it runs on compute instances provisioned by Snowflake from the cloud provider, so it is not something a customer sizes or installs.

A useful shorthand: cloud services decides what should happen; a warehouse makes it happen; storage keeps what happened.

Follow one request through the layers

Putting the layers in order turns the architecture into a sequence you can narrate.

For a query request, cloud services performs coordination such as authentication, metadata handling, parsing, optimization, and dispatch. The selected virtual warehouse then supplies the independent compute resources that execute the work. Persisted table data remains in centrally accessible cloud storage rather than being owned by one warehouse.

The handoff at step 3 is the one worth memorizing. If a request has been authenticated and parsed but nothing has executed yet, what comes next is dispatch to the selected warehouse.

The alternatives are all layer confusions:

• Database storage does not authenticate requests on compute nodes; authentication is a cloud-services function.
• A warehouse does not relocate persisted data into private-cloud storage; the data stays in centrally accessible public-cloud storage.
• A client driver does not optimize and execute the query on its own; optimization is coordinated by cloud services and execution that needs compute uses a warehouse.

This separation is the payoff of the whole design: it lets multiple independent warehouses access the same persisted data while isolating their compute resources.

Key takeaways

• Snowflake is a self-managed public-cloud service. Customers do not select, install, configure, or manage the hardware, and the platform cannot be installed locally or on private-cloud infrastructure, whether on-premises or hosted.
• The hybrid architecture combines centrally accessible persisted storage with massively parallel compute clusters, giving shared-disk simplicity together with shared-nothing performance and scale-out.
• Database storage persists managed data, reorganized into an optimized, compressed, columnar format and divided into micro-partitions, with organization, file size, structure, compression, metadata, and statistics handled by Snowflake.
• Virtual warehouses execute work independently, so one warehouse's workload does not affect another's performance even when both read the same tables.
• Cloud services coordinates requests and platform-wide services, from sign-in and access control through metadata, parsing, optimization, and dispatch.