Snowflake Caching Explained: Query Results, Metadata and Warehouse Cache

Snowflake caching is one of the most powerful — and often overlooked — features for improving query performance and reducing compute costs. Snowflake’s architecture includes three distinct caching layers, each operating at a different level of the platform. Understanding how they work can significantly speed up your queries and lower your Snowflake bill.

In this guide, we break down each of the three Snowflake cache types, where they live in the architecture, how long they persist, and how to write queries that benefit from them.

Why Caching Matters in Snowflake

Snowflake’s pricing model is compute-based — you pay for the time your virtual warehouses are running. Every query answered from cache instead of spinning up compute saves both time and money. Snowflake was designed from the ground up with caching in mind, and its three-layer cache system is one of the core reasons it performs so well at scale.

The key insight: not all caches in Snowflake are equal. They live in different architectural layers, have different persistence lifetimes, and serve different purposes. Knowing which one applies to your query is the difference between a 100ms result and a 30-second warehouse spin-up.

The Three Types of Snowflake Cache

Snowflake’s architecture is divided into three layers:

• Cloud Services Layer — handles authentication, query optimization, and metadata
• Compute Layer — virtual warehouses that execute queries
• Storage Layer — where your actual data lives in micro-partitions

Two of the three caches live in the Cloud Services Layer, and one lives in the Compute Layer.

1. Query Results Cache

What It Is

The Query Results Cache is the most powerful cache in Snowflake. When you execute a query, Snowflake stores the result set in the Cloud Services Layer. If the exact same query is run again — by any user in the same account — Snowflake returns the cached result instantly without executing the query or consuming any compute credits.

How Long It Lasts

• Results are cached for 24 hours by default
• If the query is re-executed within that 24-hour window and the underlying data has not changed, the timer resets
• This rolling reset can extend cache validity for up to 31 days
• If the underlying table data changes, the cache is immediately invalidated

What Triggers a Cache Hit

For the Query Results Cache to be used, all of the following must be true:

1. The SQL query text is identical (including whitespace and casing)
2. The same database objects are referenced
3. The underlying data has not changed since the cache was created
4. The user has the same role and access privileges

Real-World Example

-- First execution: runs on warehouse, result cached
SELECT region, SUM(sales_amount)
FROM orders
WHERE order_date >= '2025-01-01'
GROUP BY region;

-- Second execution (within 24h, no data change): instant, zero compute cost
SELECT region, SUM(sales_amount)
FROM orders
WHERE order_date >= '2025-01-01'
GROUP BY region;

When to Use It

This cache is ideal for dashboard queries and scheduled reports that run on fixed datasets. If your BI tool re-runs the same query every time a user opens a dashboard, the Query Results Cache means only the first load hits the warehouse.

2. Metadata Cache

What It Is

The Metadata Cache lives in the Cloud Services Layer and stores structural information about your Snowflake objects — tables, schemas, databases, micro-partitions, and more. This includes row counts, table size, min/max values per column, micro-partition details, and NULL counts.

What It Powers

The Metadata Cache allows Snowflake to answer certain queries without touching the Compute Layer at all:

-- Answered directly from metadata — no warehouse needed
SHOW TABLES;
SELECT COUNT(*) FROM orders;
DESCRIBE TABLE customers;

Snowflake’s query optimizer also uses the Metadata Cache for micro-partition pruning — skipping irrelevant data partitions before a query even starts. This is one of Snowflake’s biggest performance advantages over traditional data warehouses.

Why It Matters

When you run a SELECT COUNT(*), most databases need to scan the entire table. Snowflake doesn’t — it reads the count directly from metadata. This is nearly instantaneous and costs zero compute credits.

For partition pruning, if your query filters on a column like order_date, Snowflake uses metadata to identify which micro-partitions contain data within that date range and skips everything else. This can reduce data scanned by 90% or more on large tables.

3. Warehouse Cache

What It Is

The Warehouse Cache (also called the Local Disk Cache) lives inside the Compute Layer, on the local SSD storage of your virtual warehouse nodes. When a query executes and reads micro-partitions from remote storage, those micro-partitions are cached locally on the warehouse SSD. Subsequent queries needing the same data read it from local SSD — significantly faster than fetching from remote storage.

How Long It Lasts

This is the critical limitation: the Warehouse Cache only persists while the warehouse is running. The moment you suspend your virtual warehouse, all locally cached data is lost. When the warehouse resumes, it starts with a cold cache.

Example

-- First query: fetches micro-partitions from remote storage, caches on SSD
SELECT * FROM events WHERE event_type = 'click' AND event_date = '2025-03-01';

-- Second query: same micro-partitions already on SSD — much faster
SELECT * FROM events WHERE event_type = 'view' AND event_date = '2025-03-01';

Implications for Warehouse Configuration

• Auto-suspend after 1 minute — saves cost but causes frequent cold starts
• Auto-suspend after 10–30 minutes — keeps cache warm for follow-up queries
• Larger warehouses — more SSD, more data cached locally

For workloads with repeated scans over the same dataset (interactive analytics), keeping auto-suspend at 10–15 minutes gives better overall performance at acceptable cost.

How the Three Caches Work Together

When a query arrives in Snowflake, the platform checks each cache layer in order before touching compute:

1. Query Results Cache hit? → Return result instantly (zero compute)
2. Metadata Cache sufficient? → Return metadata result (zero compute)
3. Warehouse running + data on SSD? → Read from local SSD (fast compute)
4. Cache miss → Fetch from remote storage (full compute cost)

This layered approach is why Snowflake can be both cost-efficient and fast — most repeated or metadata-driven queries never touch compute at all.

Best Practices to Maximize Cache Hits

For Query Results Cache

• Standardize query text in your BI tools — even a single space difference creates a miss
• Avoid using current_timestamp() in cached queries — it changes every run
• Use static date filters for historical data queries

-- Bad: Will never hit cache
SELECT * FROM orders WHERE created_at > DATEADD('day', -7, CURRENT_TIMESTAMP());
-- Good: Will hit cache
SELECT * FROM orders WHERE created_at > '2025-03-07';

For Metadata Cache

• Cluster tables on frequently filtered columns for better partition pruning
• Use SHOW commands instead of querying information_schema for object metadata
• *Use SELECT COUNT()** directly — it reads from metadata, not data

For Warehouse Cache

• Set auto-suspend to 10–15 minutes for interactive analytics workloads
• Use dedicated warehouses per workload — each builds its own relevant cache
• Avoid frequent warehouse resizes — a resize clears the SSD cache

Common Caching Mistakes to Avoid

Conclusion

Snowflake’s three caching layers work together to deliver fast query performance while keeping compute costs low:

• Repeated identical queries → Query Results Cache (zero compute, up to 31 days)
• Structural and count queries → Metadata Cache (instant, no compute)
• Repeated scans over same data → Warehouse Cache (fast SSD reads, keep warehouse warm)

Designing your queries and warehouse configuration with these caching layers in mind is one of the most impactful — and often overlooked — optimizations in Snowflake. Whether you are building dashboards, running ETL pipelines, or doing ad hoc analytics, understanding which cache layer applies to your workload will make you a significantly more effective data engineer.