Skip to main content
Once Delphina is connected to Snowflake, the main thing that determines whether it feels fast or flaky is how the warehouse behind it is sized and scaled. This guide covers our learned defaults for sizing, when to scale out versus up, and how to have Delphina diagnose your specific account.
The right numbers vary a lot by workload. Start with the defaults below, then use the monitoring prompts to tune from your account’s real behavior.

​
Why the 2-minute target matters

Delphina enforces a 120-second timeout on every warehouse query. A query that hasn’t returned by then is cancelled and surfaces to the user as a failure. This cap is deliberate — it acts as a circuit breaker. When a warehouse gets slow (a cluster is saturated, a large scan is running), queries would otherwise sit in Snowflake’s queue and pile up behind each other, with every new query inheriting an ever-growing wait. Cancelling at 120 seconds bounds how long any single query can hold a warehouse slot, so a temporary slowdown doesn’t cascade into a much longer queue on your side. The practical implication: size your warehouse so the queries you care about finish comfortably under 2 minutes, including any time spent queued. Queue time and execution time share the same budget. Repeated timeouts aren’t just errors to dismiss — they’re the signal that the warehouse needs to scale.

​
The two scaling knobs

Snowflake gives you two independent controls, and they fix two different problems:
Start by scaling out, not up. Delphina issues many independent queries concurrently (exploration, validation, pipeline steps), so the common failure mode is queueing, not a single query being too big. Adding clusters removes the queue; upsizing only helps if individual queries are genuinely too slow.
A dedicated, multi-cluster warehouse for Delphina:
  • WAREHOUSE_SIZE = 'SMALL' — the smallest size that keeps your important queries under ~90s (leaving headroom below the 120s cutoff). Go larger only if monitoring shows individual queries running long.
  • MAX_CLUSTER_COUNT is your concurrency ceiling. If monitoring shows sustained queueing, raise this before touching size.
  • AUTO_SUSPEND = 60 keeps costs down between bursts without cold-starting on every query.
  • Use a dedicated warehouse for Delphina rather than sharing one with human analysts or ETL. It isolates Delphina’s concurrency behavior and makes the monitoring queries below clean to interpret.

​
Parallel warehouses (advanced)

If different Delphina workloads have very different query profiles — cheap interactive queries versus heavy pipeline scans — consider separate warehouses per workload so a run of heavy queries can’t starve interactive ones. Each is sized and scaled independently. Start with a single multi-cluster warehouse and only split if monitoring shows contention.

​
Monitoring for queueing

You don’t need to build dashboards — ask Delphina. It has read access to your Snowflake query history and can identify its own service-account queries and summarize their runtime and queueing behavior.
This requires query-history access. Delphina’s full-history monitoring reads SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY, which needs the IMPORTED PRIVILEGES grant from Step 3 of the connection guide. Without it, monitoring falls back to a 7-day, service-account-only window.
To run the full diagnosis and get a concrete scale-out-vs-scale-up recommendation, paste this prompt into a Delphina chat:

​
Reading the results