Snowflake

3 roadmaps 36 questionsupdated 2026-09-29

Snowflake is the managed warehouse where storage, compute and cloud services scale as three separate layers, billed by the second. Interviewers ask about it because that separation changes how I reason about concurrency, tuning and cost compared with a fixed cluster.

▸ follow the snowflake roadmap jump to the questions →

on this pageshow

guide

overview

~1 min

The hub follows that split. Architecture overview sets out the three layers and what each makes possible. Virtual warehouses covers compute: sizing, suspending, and adding clusters under concurrency. Micro-partitions and clustering explains how Snowflake finds rows without indexes. Data loading and stages is the ingest path, from bulk files to continuous arrival and semi-structured JSON. Data sharing and the Marketplace is its most distinctive feature. Cost and performance tuning ties it together: where credits go, which caches make repeats cheap, and how to read a Query Profile.

Junior rounds check the model: the layers, what a warehouse is, why a filter can skip most of a table. Senior and principal rounds turn into diagnosis: a warehouse that never stops billing, a clustered table that still scans everything, a partner feed where a share is the wrong tool.

Start with the architecture, then warehouses and micro-partitions. Loading, sharing and tuning all assume those three.

Snowflake is a managed cloud data warehouse built as three independent layers: table data held once in a cloud object store, compute supplied by virtual warehouses you size and start on demand, and a cloud services layer that owns the catalog, query planning, transactions and access control. Interviewers use it to test whether you can reason about compute that is rented by the second rather than owned: most strong answers name which layer does the work and who pays for it. The hub follows that split. [Architecture overview](/topics/db-snowflake-architecture) sets out the three layers and what each makes possible. [Virtual warehouses](/topics/db-snowflake-virtual-warehouses) covers compute: sizing, suspending, and adding clusters under concurrency. [Micro-partitions and clustering](/topics/db-snowflake-storage-clustering) explains how Snowflake finds rows without indexes. [Data loading and stages](/topics/db-snowflake-data-loading) is the ingest path, from bulk files to continuous arrival and semi-structured JSON. [Data sharing and the Marketplace](/topics/db-snowflake-data-sharing) is its most distinctive feature. [Cost and performance tuning](/topics/db-snowflake-cost-performance) ties it together: where credits go, which caches make repeats cheap, and how to read a Query Profile. Junior rounds check the model: the layers, what a warehouse is, why a filter can skip most of a table. Senior and principal rounds turn into diagnosis: a warehouse that never stops billing, a clustered table that still scans everything, a partner feed where a share is the wrong tool. Start with the architecture, then warehouses and micro-partitions. Loading, sharing and tuning all assume those three.

primer

Storage and compute are separate bills

Table data lives once, in cloud object storage, and no warehouse owns it. Many warehouses can read the same tables at once without competing for CPU, and a warehouse can be created, resized or dropped without touching data. That is why isolating a noisy workload usually means giving it its own warehouse, and why capacity planning becomes a conversation about credits rather than hardware.

Compute is rented by the second

A virtual warehouse runs only while it has work or has not yet hit its idle timeout. Each size step doubles both the nodes and the rate, so a job that parallelises well can finish in half the time for roughly the same spend. Two different levers answer two different problems:

Scaling up (a bigger size) helps a single heavy query, especially one spilling to disk.
Scaling out (more clusters of the same size) helps many queries waiting in a queue.

Picking the wrong lever is one of the most common senior-round mistakes.

Files are immutable, and metadata is the index

Snowflake writes each table as many small columnar files, micro-partitions, and never edits one in place; changes write new files. The services layer records value ranges for every file, and the optimizer uses them to skip files a filter cannot match. There are no conventional indexes to build; performance depends on how well the physical order of rows matches the filters people actually run, which is what clustering is for.

Immutability pays for several features

Because old files are kept rather than overwritten, the same storage model gives you zero-copy cloning, Time Travel to query or restore earlier versions, and secure sharing with another account. Each is mostly a metadata operation over files that already exist. When an interviewer asks how any of them can be instant, the answer starts from immutable files.

The services layer is always on

Planning, metadata, transactions and the result cache sit in a shared layer that runs whether or not a warehouse does. Some statements finish there without any warehouse at all, and every warehouse writing to a table goes through the same transaction manager, so there is one history per table no matter how many clusters touch it.

### Storage and compute are separate bills Table data lives once, in cloud object storage, and no warehouse owns it. Many warehouses can read the same tables at once without competing for CPU, and a warehouse can be created, resized or dropped without touching data. That is why isolating a noisy workload usually means giving it its own warehouse, and why capacity planning becomes a conversation about credits rather than hardware. ### Compute is rented by the second A virtual warehouse runs only while it has work or has not yet hit its idle timeout. Each size step doubles both the nodes and the rate, so a job that parallelises well can finish in half the time for roughly the same spend. Two different levers answer two different problems: - **Scaling up** (a bigger size) helps a single heavy query, especially one spilling to disk. - **Scaling out** (more clusters of the same size) helps many queries waiting in a queue. Picking the wrong lever is one of the most common senior-round mistakes. ### Files are immutable, and metadata is the index Snowflake writes each table as many small columnar files, **micro-partitions**, and never edits one in place; changes write new files. The services layer records value ranges for every file, and the optimizer uses them to skip files a filter cannot match. There are no conventional indexes to build; performance depends on how well the physical order of rows matches the filters people actually run, which is what clustering is for. ### Immutability pays for several features Because old files are kept rather than overwritten, the same storage model gives you **zero-copy cloning**, **Time Travel** to query or restore earlier versions, and **secure sharing** with another account. Each is mostly a metadata operation over files that already exist. When an interviewer asks how any of them can be instant, the answer starts from immutable files. ### The services layer is always on Planning, metadata, transactions and the result cache sit in a shared layer that runs whether or not a warehouse does. Some statements finish there without any warehouse at all, and every warehouse writing to a table goes through the same transaction manager, so there is one history per table no matter how many clusters touch it.

Virtual warehouse: A named compute cluster that runs queries, DML and loads against shared storage. It holds no table data and bills only while running.
Credit: Snowflake's unit of compute billing, consumed by running warehouses, serverless features and cloud services beyond an allowance. Storage is priced separately.
Cloud services layer: The always-on layer that holds metadata and statistics, plans queries, coordinates transactions, enforces access control and keeps the result cache.
Micro-partition: An immutable, compressed columnar file holding a slice of a table's rows, created automatically, with value-range metadata recorded for every column.
Partition pruning: Skipping micro-partitions whose recorded value ranges cannot satisfy a query's filter, so they are never read. It does the job indexes do elsewhere.
Clustering key: Columns or expressions declared on a table so rows with similar values are stored together, making pruning more effective. Maintained by a background service.
Clustering depth: How many micro-partitions overlap for a given key value. Low depth means filters on that key can skip most of the table.
Stage: A named location holding data files for loading or unloading: internal, managed by Snowflake, or external, pointing at a cloud storage bucket.
Snowpipe: Serverless continuous loading that ingests files shortly after they land in a stage, billed per use rather than through your warehouse.
VARIANT: A column type that stores semi-structured data such as JSON, queried by path and cast to typed values when read.
Share: An object granting another account read-only access to selected databases, tables or secure views without copying data.
Result cache: Stored results of recent queries, kept in the services layer and reused for an identical query when underlying data has not changed.
Zero-copy clone: A new table, schema or database that initially points at the source's existing files, so creating it copies metadata rather than data.
Time Travel: Access to a table's earlier states within a retention window, used to query past data, undo changes or restore dropped objects.

Every other section attaches to one of those steps:

Loading writes new micro-partitions, through a warehouse for COPY INTO or serverless compute for Snowpipe, so file sizing and arrival pattern decide both latency and cost.
Clustering changes which files a filter can skip; a background service rewrites files to keep it, and bills for doing so.
Sharing hands another account the same metadata pointers. The consumer's own warehouse does the reading, which is why a share is live but stays within one region.
Tuning is reading which step dominated: queueing, scanning too many files, spilling memory, or a warehouse that never idles.

The same three layers show up in plain DDL:

sql

-- compute: sized for one workload, stops when idle
CREATE WAREHOUSE bi_wh
  WAREHOUSE_SIZE = 'MEDIUM' AUTO_SUSPEND = 60 AUTO_RESUME = TRUE;

-- storage: a full dev copy that moves no bytes
CREATE DATABASE analytics_dev CLONE analytics;

-- sharing: another account reads the same files
CREATE SHARE partner_share;
GRANT USAGE ON DATABASE analytics TO SHARE partner_share;
GRANT USAGE ON SCHEMA analytics.public TO SHARE partner_share;
GRANT SELECT ON VIEW analytics.public.partner_orders TO SHARE partner_share;

None of these statements moves data. The clone adds storage only as its files diverge from the source, and the warehouse bills only between resume and suspend. The shared object is a secure view, which is also where per-consumer row filtering lives.

Follow one query. A client connects and the cloud services layer authenticates it, checks privileges and parses the SQL. If an identical earlier result is still valid, it is returned from the result cache and no warehouse starts. Otherwise the optimizer compares the filters with micro-partition metadata, prunes what cannot match, and hands a plan to a warehouse, resuming it if it was suspended. The warehouse reads the surviving files from object storage, keeping recently used column data on local disk, and returns the result. The warehouse bills for the seconds it runs, not for the query. Every other section attaches to one of those steps: - **Loading** writes new micro-partitions, through a warehouse for `COPY INTO` or serverless compute for Snowpipe, so file sizing and arrival pattern decide both latency and cost. - **Clustering** changes which files a filter can skip; a background service rewrites files to keep it, and bills for doing so. - **Sharing** hands another account the same metadata pointers. The consumer's own warehouse does the reading, which is why a share is live but stays within one region. - **Tuning** is reading which step dominated: queueing, scanning too many files, spilling memory, or a warehouse that never idles. The same three layers show up in plain DDL: ```sql -- compute: sized for one workload, stops when idle CREATE WAREHOUSE bi_wh WAREHOUSE_SIZE = 'MEDIUM' AUTO_SUSPEND = 60 AUTO_RESUME = TRUE; -- storage: a full dev copy that moves no bytes CREATE DATABASE analytics_dev CLONE analytics; -- sharing: another account reads the same files CREATE SHARE partner_share; GRANT USAGE ON DATABASE analytics TO SHARE partner_share; GRANT USAGE ON SCHEMA analytics.public TO SHARE partner_share; GRANT SELECT ON VIEW analytics.public.partner_orders TO SHARE partner_share; ``` None of these statements moves data. The clone adds storage only as its files diverge from the source, and the warehouse bills only between resume and suspend. The shared object is a secure view, which is also where per-consumer row filtering lives.

Architecture Overview →
The three-layer split that every later answer on caching, scaling, sharing and cost refers back to.
Virtual Warehouses →
Compute as a billable object: sizing, suspend and resume, and scaling up versus scaling out.
Micro-partitions & Clustering →
How micro-partitions and pruning replace indexes, and when a clustering key earns its maintenance cost.
Data Loading & Stages →
Stages, bulk loads versus Snowpipe, and semi-structured data, which all produce the micro-partitions you just studied.
Data Sharing & Marketplace →
Live access for other accounts without copies; it makes sense once storage and compute separation is clear.
Cost & Performance Tuning →
Credits, caches and the Query Profile, where every earlier section becomes a diagnosis.

Answering every slow query with a larger warehouse before checking pruning and spilling in the Query Profile; a scan of the whole table stays a scan at any size.
Mixing up the two scaling levers: a bigger size helps one heavy query, while extra clusters help queued concurrency and do nothing for a single slow statement.
Calling a clustering key an index, or adding one to a small or heavily rewritten table where reclustering credits outweigh the scans it saves.
Filtering through a function or cast on the clustered column and expecting pruning to survive; the optimizer can only compare against stored value ranges.
Setting a very short auto-suspend as if it were free: every resume bills a minimum, and a suspended warehouse loses its local disk cache.
Declaring a primary key and expecting Snowflake to reject duplicates; it records the constraint but enforces only NOT NULL, so dedupe in the load itself.
Assuming a direct share copies data or reaches any account; it is live, read-only and limited to one region unless the data is replicated first.

Around it sit the tools you will be asked to wire in. dbt is the common way to build and test transformations inside the warehouse. Ingestion tools such as Fivetran or Airbyte, and Kafka through its connector, feed stages and tables. Apache Iceberg tables let Snowflake read and write data in an open format that other engines can also use, which is often the answer to "how do we avoid lock-in".

Interviewers expect you to place Snowflake among the other cloud warehouses and lakehouse platforms. Google BigQuery is the closest comparison in operating model: fully managed and serverless, with compute allocated by the service rather than through warehouses you name and size. Amazon Redshift began as a cluster-based warehouse where compute and storage were provisioned together, and interviewers still use it to contrast fixed clusters with Snowflake's elastic warehouses. Databricks comes from the Spark and data-lake side and competes where teams want open file formats, notebooks and machine learning next to SQL; the trade-off usually argued is a managed, SQL-first warehouse against a more open, engineering-heavy platform. Around it sit the tools you will be asked to wire in. dbt is the common way to build and test transformations inside the warehouse. Ingestion tools such as Fivetran or Airbyte, and Kafka through its connector, feed stages and tables. Apache Iceberg tables let Snowflake read and write data in an open format that other engines can also use, which is often the answer to "how do we avoid lock-in".

explore

Architecture Overview6 questions
Virtual Warehouses5 questions
Micro-partitions & Clustering6 questions
Data Loading & Stages6 questions
Data Sharing & Marketplace6 questions
Cost & Performance Tuning7 questions

report an issue with this guide →

questions

page 1 of 2

What are the three layers of Snowflake's architecture, and what does each one own?

juniormust knowfreq 85%

answer

three concerns, three independent bills
the bytes never live on the compute nodes
compute clusters have a name of their own
the brain above both is multi-tenant
storage, virtual warehouses, cloud services

basics

~20 s

Snowflake separates storage (compressed columnar data in cloud object storage), compute (virtual warehouses, independent clusters that run queries), and cloud services (metadata, query optimization, transactions, security). The three layers scale independently and are billed separately.

solid answer

~40 s

Snowflake is a three-layer system. Database storage: loaded data is rewritten into Snowflake's own compressed columnar files and kept in cloud object storage (S3, Azure Blob, or GCS) in the account's region; you only reach it through SQL. Query processing: a virtual warehouse is a cluster of compute nodes with its own CPU, memory and local SSD cache that reads what it needs from the storage layer. Many warehouses can run against the same tables at once without contending for each other's resources. Cloud services: the multi-tenant control plane that owns authentication and role-based access control, the catalog and file-level metadata, query parsing and optimization, transaction management, and the result cache. Because storage and compute are decoupled, you can grow data without buying compute, and add or resize a warehouse without moving a byte.

Snowflake is a **three-layer** system. **Database storage**: loaded data is rewritten into Snowflake's own compressed columnar files and kept in cloud object storage (S3, Azure Blob, or GCS) in the account's region; you only reach it through SQL. **Query processing**: a *virtual warehouse* is a cluster of compute nodes with its own CPU, memory and local SSD cache that reads what it needs from the storage layer. Many warehouses can run against the same tables at once without contending for each other's resources. **Cloud services**: the multi-tenant control plane that owns authentication and role-based access control, the catalog and file-level metadata, query parsing and optimization, transaction management, and the result cache. Because storage and compute are decoupled, you can grow data without buying compute, and add or resize a warehouse without moving a byte.

code

sql · 7 lines

sql

-- Two independent compute clusters over the SAME stored table
USE WAREHOUSE etl_wh;
INSERT INTO sales SELECT * FROM staging_sales;

-- different session, different warehouse, no contention
USE WAREHOUSE bi_wh;
SELECT region, SUM(amount) FROM sales GROUP BY region;

go deeper

for a junior

Be able to name the three layers and one responsibility of each without hesitating. Knowing that data sits in cloud object storage and that compute clusters are called virtual warehouses is the bar here.

for a middle

Explain what each layer is billed for and why storage and compute scale separately. Expect to be asked which layer holds metadata, which holds the result cache, and what a warehouse actually caches locally.

for a senior

Show you use the split operationally: sizing and isolating warehouses per workload, reasoning about cold-cache behaviour after a suspend, and knowing that pruning decisions happen in cloud services before the warehouse reads anything.

for a principal

Own the consequences at platform scale — warehouse topology per team, credit accountability per layer, and where the shared multi-tenant services layer becomes a coupling point across an organization's accounts.

Why the split exists

Classic warehouse appliances bind data to the machine that stores it: each node owns a slice of every table, so adding compute means redistributing data, and one heavy workload starves every other one on the box. Snowflake's design pulls those concerns apart into three layers that scale, fail and get billed independently. Almost every other Snowflake answer — caching, concurrency, cost, cloning — is a consequence of this split, which is why interviewers open here.

Layer 1 — database storage

When you load data, Snowflake does not keep your CSV or Parquet file. It reorganizes the rows into its own compressed, columnar internal format and writes them as immutable files (Snowflake calls them micro-partitions) into the cloud provider's object storage — Amazon S3, Azure Blob Storage, or Google Cloud Storage — inside the region the account lives in. You cannot open those files directly; the only access path is SQL through Snowflake. Alongside the data, Snowflake records per-file, per-column metadata (value ranges, counts, distinct-value information) that later drives pruning.

Storage is billed on the average compressed bytes stored per month and is completely independent of whether any compute is running. A table you never query costs storage and nothing else.

Layer 2 — query processing (virtual warehouses)

A virtual warehouse is a cluster of compute nodes Snowflake provisions on your behalf. Each warehouse has its own CPU, memory and local SSD; it pulls the file chunks it needs from the storage layer and caches them on that local SSD for reuse. Warehouses are shared-nothing among themselves: warehouse ETL_WH and warehouse BI_WH share no compute state, so a heavy transformation cannot slow a dashboard running on the other warehouse. Any number of warehouses can read (and write) the same tables concurrently, because they all point at the same storage.

Warehouses can be created, resized, suspended and resumed in seconds — nothing has to be redistributed, because they own no data. Credits are consumed only while a warehouse is running.

Layer 3 — cloud services

This is the brain, and it is a multi-tenant service Snowflake operates across accounts. It owns:

authentication, sessions, and role-based access control;
the catalog and all object metadata, including the per-file statistics used for pruning;
SQL parsing, optimization and compilation, and query dispatch to a warehouse;
transaction management and the ACID guarantees over the shared storage;
the query result cache and infrastructure management (provisioning warehouse nodes).

Nothing here belongs to a single warehouse. That is exactly why metadata and cached results are shared account-wide, and why some statements complete with no warehouse running at all. Cloud services consumption is metered in credits, but Snowflake charges only the portion of daily cloud-services credits that exceeds 10% of that day's warehouse credits, so for normal workloads it rounds to nothing.

What the architecture buys you

Independent scaling. Data growth never forces a compute purchase, and a bigger warehouse never forces a data reload.
Workload isolation. ELT, BI and data science each get their own warehouse over one copy of the data — no extracts, no marts kept in sync.
Elasticity. Resize or spin up a warehouse in seconds because there is no data to move.
Cheap metadata operations. Clones and time travel are pointer manipulations over immutable files, not copies.

What it costs you

A cold warehouse pays object-store latency on its first scan until its local cache fills.
An idle running warehouse burns credits for nothing, so suspend policy is a real cost lever.
Compilation is centralized: a very large plan can spend meaningful time in the services layer before any data is read.
Nothing about this design targets single-row OLTP access; there are no user-managed indexes in the traditional sense.

Interview framing

The follow-up is usually "which layer does X live in?" Be able to place: pruning statistics (services metadata, describing storage), the query result cache (services, shared by all warehouses), the local data cache (inside one warehouse, lost on suspend), RBAC and the optimizer (services), the actual bytes (storage).

## Why the split exists Classic warehouse appliances bind data to the machine that stores it: each node owns a slice of every table, so adding compute means redistributing data, and one heavy workload starves every other one on the box. Snowflake's design pulls those concerns apart into three layers that scale, fail and get billed independently. Almost every other Snowflake answer — caching, concurrency, cost, cloning — is a consequence of this split, which is why interviewers open here. ## Layer 1 — database storage When you load data, Snowflake does not keep your CSV or Parquet file. It reorganizes the rows into its own **compressed, columnar** internal format and writes them as immutable files (Snowflake calls them micro-partitions) into the cloud provider's object storage — Amazon S3, Azure Blob Storage, or Google Cloud Storage — inside the region the account lives in. You cannot open those files directly; the only access path is SQL through Snowflake. Alongside the data, Snowflake records per-file, per-column metadata (value ranges, counts, distinct-value information) that later drives pruning. Storage is billed on the average compressed bytes stored per month and is completely independent of whether any compute is running. A table you never query costs storage and nothing else. ## Layer 2 — query processing (virtual warehouses) A **virtual warehouse** is a cluster of compute nodes Snowflake provisions on your behalf. Each warehouse has its own CPU, memory and local SSD; it pulls the file chunks it needs from the storage layer and caches them on that local SSD for reuse. Warehouses are shared-nothing among themselves: warehouse `ETL_WH` and warehouse `BI_WH` share no compute state, so a heavy transformation cannot slow a dashboard running on the other warehouse. Any number of warehouses can read (and write) the same tables concurrently, because they all point at the same storage. Warehouses can be created, resized, suspended and resumed in seconds — nothing has to be redistributed, because they own no data. Credits are consumed only while a warehouse is running. ## Layer 3 — cloud services This is the brain, and it is a **multi-tenant** service Snowflake operates across accounts. It owns: - authentication, sessions, and role-based access control; - the catalog and all object metadata, including the per-file statistics used for pruning; - SQL parsing, optimization and compilation, and query dispatch to a warehouse; - transaction management and the ACID guarantees over the shared storage; - the **query result cache** and infrastructure management (provisioning warehouse nodes). Nothing here belongs to a single warehouse. That is exactly why metadata and cached results are shared account-wide, and why some statements complete with no warehouse running at all. Cloud services consumption is metered in credits, but Snowflake charges only the portion of daily cloud-services credits that exceeds 10% of that day's warehouse credits, so for normal workloads it rounds to nothing. ## What the architecture buys you - **Independent scaling.** Data growth never forces a compute purchase, and a bigger warehouse never forces a data reload. - **Workload isolation.** ELT, BI and data science each get their own warehouse over one copy of the data — no extracts, no marts kept in sync. - **Elasticity.** Resize or spin up a warehouse in seconds because there is no data to move. - **Cheap metadata operations.** Clones and time travel are pointer manipulations over immutable files, not copies. ## What it costs you - A cold warehouse pays object-store latency on its first scan until its local cache fills. - An idle running warehouse burns credits for nothing, so suspend policy is a real cost lever. - Compilation is centralized: a very large plan can spend meaningful time in the services layer before any data is read. - Nothing about this design targets single-row OLTP access; there are no user-managed indexes in the traditional sense. ## Interview framing The follow-up is usually "which layer does X live in?" Be able to place: pruning statistics (services metadata, describing storage), the query result cache (services, shared by all warehouses), the local data cache (inside one warehouse, lost on suspend), RBAC and the optimizer (services), the actual bytes (storage).

If you suspend a virtual warehouse, what is lost and what survives?
The data itself and all metadata survive — they live in the storage and cloud services layers, not on the warehouse. What is lost is the warehouse's local SSD cache, so the next query after resume re-reads from object storage and runs colder. Query results already in the account-wide result cache still serve, because that cache belongs to cloud services.
Which layer decides how much data a query actually reads?
Cloud services. The optimizer consults the per-file column metadata it keeps about the storage layer and eliminates files whose value ranges cannot satisfy the predicate, then hands the surviving file list to the warehouse. The warehouse only fetches and scans what it is told to.
Can two Snowflake accounts share the same storage layer?
Not directly — each account's tables live in storage Snowflake manages for that account. Cross-account access is granted through Snowflake's secure sharing features, where the consumer queries the provider's data with the consumer's own compute; no copy is made and no files change hands.

Think of a public library: the shelves hold one copy of every book (storage), any number of reading rooms can work from those shelves at once (virtual warehouses), and the catalog, librarians and membership desk sit above both (cloud services).

saying these in an interview costs you the question

Says data is copied onto the warehouse nodes permanently
Claims each warehouse owns a slice of the table
Thinks storage costs stop when warehouses are suspended
Puts the query optimizer inside the virtual warehouse
Calls Snowflake pure shared-nothing like a classic MPP appliance

§guide

overview

§primer

▾core ideas2 ideas

Storage and compute are separate bills

Compute is rented by the second

Files are immutable, and metadata is the index

Immutability pays for several features

The services layer is always on

▾vocabulary14 terms

▾how it fits~2 min

▾where to start6 steps

▾common pitfalls7

▾ecosystem~60 s

§explore

▾sections6 · 36 questions

▾roadmaps that cover this3

§questions

What are the three layers of Snowflake's architecture, and what does each one own?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

Why the split exists

Layer 1 — database storage

Layer 2 — query processing (virtual warehouses)

Layer 3 — cloud services

What the architecture buys you

What it costs you

Interview framing

▾common follow-ups3 questions

▾analogy~20 s

▾red flags5 flags

§ context

▾related questions10 questions

▾related topics4 topics

In Snowflake, what actually consumes credits, and what is billed outside the credit meter?

basics

In Snowflake, what are internal and external stages, and how do files get into each?

basics

Why can a Snowflake query filter a huge table fast when Snowflake has no indexes?

basics

In Snowflake, what is a virtual warehouse and what changes when you resize it from X-Small to Large?

basics

Why is Snowflake described as a hybrid of shared-disk and shared-nothing architecture?

basics

How do Snowflake's query result cache and a virtual warehouse's local disk cache differ?

basics

How does Snowflake's COPY INTO avoid reloading a file, and when does that protection lapse?

basics

In Snowflake, how do you query a JSON array inside a VARIANT column using LATERAL FLATTEN?

basics

In Snowflake, what does a secure data share give a consumer account, and what gets copied?

basics

What is a Snowflake micro-partition, and why does its immutability matter?

basics

How do you configure a Snowflake multi-cluster warehouse, and what does SCALING_POLICY = 'ECONOMY' change?

basics

In Snowflake's Query Profile, which statistics tell you why a query is slow, and what fix does each imply?

basics

In a Snowflake share, how do you let each consumer account see only its own rows?

basics

Which Snowflake operations complete without a running virtual warehouse, and why?

basics

In Snowflake, what does a resource monitor do when its credit quota is reached?

basics

Why does one 50 GB gzipped CSV load slowly into Snowflake even on a large warehouse?

basics

In Snowflake, how do you share data with a partner that has no Snowflake account?

basics

What does CLUSTER BY do to a Snowflake table, and who maintains that ordering?

basics

In Snowflake, what do a warehouse's AUTO_SUSPEND and AUTO_RESUME settings do, and what is the tradeoff?

basics

Two Snowflake virtual warehouses write to one table concurrently — what does each session see?

basics

How does Snowflake's architecture make CREATE TABLE ... CLONE of a 10 TB table instant?

guide

primer

explore

questions

answer

go deeper

context