Snowflake Multi-Cluster Warehouses
Multi-cluster warehouses in Snowflake automatically scale compute resources based on workload demands, ensuring consistent performance while optimizing costs.
Scaling Policies
Snowflake supports two scaling policies that determine when additional clusters are added or removed:
STANDARD Policy
The STANDARD policy scales up immediately when all existing clusters reach 100% utilization. This prioritizes query performance over cost, making it ideal for production workloads where latency is critical. Snowflake will add a new cluster as soon as the current cluster queue depth exceeds a threshold.
ECONOMY Policy
The ECONOMY policy introduces a delay before scaling up, waiting at least 6 minutes at 100% utilization before adding a cluster. This reduces costs by avoiding rapid scaling for brief spikes, making it suitable for development, testing, and non-critical analytics workloads. Scale-down happens more aggressively to minimize idle clusters.
Creating Multi-Cluster Warehouses
-- Create a multi-cluster warehouse with STANDARD policy
CREATE OR REPLACE WAREHOUSE analytics_mcw
WAREHOUSE_SIZE = 'MEDIUM'
MIN_CLUSTERS = 1
MAX_CLUSTERS = 5
SCALING_POLICY = 'STANDARD'
AUTO_SUSPEND = 300
AUTO_RESUME = TRUE
INITIALLY_SUSPENDED = FALSE
COMMENT = 'Multi-cluster warehouse for analytics workloads';
-- Create an ECONOMY policy warehouse for batch jobs
CREATE OR REPLACE WAREHOUSE etl_mcw
WAREHOUSE_SIZE = 'LARGE'
MIN_CLUSTERS = 1
MAX_CLUSTERS = 8
SCALING_POLICY = 'ECONOMY'
AUTO_SUSPEND = 600
AUTO_RESUME = TRUE
COMMENT = 'Economy multi-cluster for ETL processing';
-- Create a multi-cluster for high-concurrency dashboards
CREATE OR REPLACE WAREHOUSE dashboard_mcw
WAREHOUSE_SIZE = 'SMALL'
MIN_CLUSTERS = 2
MAX_CLUSTERS = 10
SCALING_POLICY = 'STANDARD'
AUTO_SUSPEND = 120
AUTO_RESUME = TRUE
COMMENT = 'High-concurrency warehouse for BI dashboards';
-- Alter an existing warehouse to add multi-cluster
ALTER WAREHOUSE existing_wh
SET
MIN_CLUSTERS = 2
MAX_CLUSTERS = 6
SCALING_POLICY = 'ECONOMY';
-- Suspend a specific cluster
ALTER WAREHOUSE analytics_mcw SUSPEND CLUSTER 2;
-- Resume a specific cluster
ALTER WAREHOUSE analytics_mcw RESUME CLUSTER 2;
Monitoring Multi-Cluster Performance
-- Check active clusters for a warehouse
SELECT
WAREHOUSE_NAME,
CLUSTER_NUMBER,
CLUSTER_STATE,
ACTIVE_QUERY_COUNT,
QUEUED_OVERLOAD_QUERIES,
QUERY_AVERGAGE_EXECUTION_TIME_MS
FROM TABLE(WAREHOUSE_LOAD_HISTORY(
DATE_RANGE_START => DATEADD('hour', -1, CURRENT_DATE()),
DATE_RANGE_END => CURRENT_DATE()
))
WHERE WAREHOUSE_NAME = 'ANALYTICS_MCW'
ORDER BY CLUSTER_NUMBER;
-- Monitor cluster scaling events
SELECT
WAREHOUSE_NAME,
EVENT_NAME,
EVENT_TIMESTAMP,
CLUSTER_NUMBER,
NEW_CLUSTER_COUNT
FROM TABLE(WAREHOUSE_EVENT_HISTORY(
DATE_RANGE_START => DATEADD('day', -7, CURRENT_DATE())
))
WHERE WAREHOUSE_NAME = 'ANALYTICS_MCW'
AND EVENT_NAME IN ('MULTI_CLUSTER_UPSCALE', 'MULTI_CLUSTER_DOWNSCALE')
ORDER BY EVENT_TIMESTAMP DESC;
-- Analyze query distribution across clusters
SELECT
CLUSTER_NUMBER,
COUNT(*) AS query_count,
AVG(EXECUTION_TIME_MS) / 1000 AS avg_exec_seconds,
P50_EXECUTION_TIME_MS / 1000 AS median_exec_seconds
FROM TABLE(INFORMATION_SCHEMA.QUERY_HISTORY(
DATE_RANGE_START => DATEADD('day', -1, CURRENT_DATE())
))
WHERE WAREHOUSE_NAME = 'ANALYTICS_MCW'
GROUP BY 1
ORDER BY 1;
Multi-Cluster vs Single-Cluster Decision Matrix
| Factor | Single-Cluster | Multi-Cluster |
|---|---|---|
| Concurrent queries | Under 10 | 10-1000+ |
| Query complexity | Simple to moderate | Any complexity |
| Peak workload predictability | Consistent | Variable/spiky |
| Cost optimization | Simpler to manage | Requires tuning |
| Scaling approach | Vertical only | Horizontal + vertical |
| Auto-suspend behavior | Single warehouse | Per-cluster suspend |
| Use case | Dev/test, small BI | Enterprise analytics, high concurrency |
Performance Metrics for Cluster Scaling
| Metric | Description | Target |
|---|---|---|
| Cluster utilization | Percentage of time clusters are active | 60-80% average |
| Queue depth | Number of queries waiting for a cluster | Under 5 |
| Scale-up latency | Time from 100% utilization to new cluster | Under 30 seconds (STANDARD) |
| Scale-down latency | Time from idle to cluster suspension | 60-600 seconds (configurable) |
| Query wait time | Time queries spend in queue | Under 10 seconds |
| Credit efficiency | Active clusters vs total available | Min cluster count when possible |
Best Practices
| Practice | Description | Impact |
|---|---|---|
| Start with MIN_CLUSTERS=1 | Let Snowflake scale from minimal baseline | Reduces initial cost |
| Use ECONOMY for batch | Delay scaling for non-critical workloads | 15-25% credit savings |
| Use STANDARD for BI dashboards | Immediate scaling for user-facing queries | Better user experience |
| Set AUTO_SUSPEND per workload | Shorter for interactive, longer for batch | Optimizes idle cost |
| Monitor queue depth regularly | Adjust MAX_CLUSTERS based on actual demand | Prevents over-provisioning |
| Use RESOURCE MONITORS | Set credit quotas per multi-cluster warehouse | Prevents cost overruns |
| Avoid MAX_CLUSTERS=10 unless needed | High max creates potential for large cost spikes | Conservative scaling |
| Review cluster distribution | Ensure queries are balanced across clusters | Consistent performance |
See Also
- Warehouse Management - Configure and manage virtual warehouses
- Architecture - Understand Snowflake's multi-cluster architecture
- Cost Management - Optimize costs for multi-cluster deployments
- Optimization - Optimize query performance across clusters