A data engineer is experiencing inconsistent query performance during peak hours. They have a single X- Small warehouse currently configured. After analyzing query history, they observed significant q

Question

Options

• AUpgrade the warehouse size to Large. This will provide more resources to handle concurrent
• BEnable auto-suspend on the warehouse to reduce credits consumed during idle periods.
• CEnable auto-resume on the warehouse to ensure it's always available.
• DEnable multi-cluster warehouse with a minimum and maximum cluster count of 2. This will scale
• ECreate a separate X-Small warehouse for each user to isolate their workloads.

• A
  31% (11)
• B
  14% (5)
• C
  8% (3)
• D
  44% (16)
• E
  3% (1)

Explanation

Multi-cluster warehouses (option D) directly solve queuing delays caused by concurrency - when one cluster is saturated, Snowflake automatically spins up a second cluster to absorb overflow queries, addressing the root cause without permanently paying for a larger size. Option A (upgrading to Large) increases compute per query but does nothing for concurrency/queuing - you'd pay 8x more credits for a problem that isn't about query speed. Options B and C (auto-suspend/auto-resume) are good cost hygiene but have zero effect on queuing; they manage idle time, not concurrent load. Option E (separate warehouse per user) would be expensive, operationally chaotic, and still doesn't intelligently route load.

Memory tip: Think of multi-cluster as a horizontal solution (more warehouses = more concurrency) vs. resizing as a vertical solution (bigger warehouse = faster individual queries). Queuing = concurrency problem = horizontal fix. If queries were slow but not queued, resizing would be the answer.

No community discussion yet for this question.