Snowflake Cost Optimization: Compute, Storage and Guardrails

Snowflake cost optimization means lowering the credits and storage an account consumes without slowing the queries people depend on. Snowflake documents total cost as the sum of three parts: compute, storage, and data transfer. Most of the controllable spend is compute, but storage settings and loading patterns add costs that warehouse tuning never touches. For how a single warehouse is billed, start with the Snowflake warehouse guide.

Compute: three kinds of credit consumption

• Virtual warehouse compute is user-managed and consumes credits while running.
• Serverless compute is used by features such as Search Optimization and Snowpipe, which run on Snowflake-managed resources that Snowflake resizes automatically.
• Cloud services compute covers authentication, metadata management, and access control. It is charged only if its daily consumption exceeds 10% of daily warehouse usage, calculated each day in UTC; serverless compute does not count toward that adjustment.

Compute levers

Match auto-suspend to the query gaps. Snowflake recommends a low value, such as 5 or 10 minutes or less, but not shorter than the regular gaps between queries, because each resume bills a 60-second minimum.

Cap runaway statements. STATEMENT_TIMEOUT_IN_SECONDS defaults to 172800 seconds, two days. And because the ABORT_DETACHED_QUERY parameter defaults to FALSE, in-progress queries are completed even after a client loses its connection, so a warehouse can keep running for them. Setting a warehouse-level timeout sized to your longest legitimate query bounds that exposure.

Size multi-cluster ranges to observed concurrency. Multi-cluster warehouses, an Enterprise Edition feature, bill for every cluster that runs. A minimum cluster count above what the load needs keeps extra clusters running; a maximum far above the observed peak removes a ceiling you may want.

Set resource monitors. A resource monitor tracks credit use against a quota over an interval and can send notifications or suspend standard warehouses when thresholds are reached. Monitors work for warehouses only, not for serverless features. Their quota counts credits from user-managed warehouses and from warehouses used by cloud services, and does not apply the daily 10% cloud services adjustment.

Storage levers

Storage is billed on the average on-disk bytes per day, at a flat per-terabyte rate that depends on account type and region. Two features add to it:

• Time Travel retains changed and deleted data for a retention period that defaults to 1 day. On Enterprise Edition and higher, permanent objects can be set anywhere from 0 to 90 days. Long retention on large, frequently rewritten tables is a direct storage cost.
• Fail-safe adds a non-configurable 7-day period after Time Travel for permanent tables. Transient tables have no Fail-safe period and so no Fail-safe storage cost, which suits data you can rebuild.

Loading and transfer

For bulk loading and Snowpipe, Snowflake recommends data files of roughly 100 to 250 MB compressed or larger; for Snowpipe, that sizing makes the per-file overhead charge immaterial relative to the data loaded. Snowflake charges no ingress fee, but charges a per-byte fee for egress out of the account’s region; the rate depends on where the account is hosted.

Where ZopNight fits

ZopNight connects to Snowflake with key-pair JWT or a personal access token and reads usage from SNOWFLAKE.ACCOUNT_USAGE, reconciling usage-based cost against those billing views. Its Snowflake recommendations cover the levers above: auto-suspend, statement timeout, multi-cluster minimum and maximum, oversized and idle warehouses, missing resource monitors, long Time Travel retention, large Fail-safe on permanent tables, cold tables, low-benefit auto-clustering and search optimization, Snowpipe small-file ingestion, and stale stages. Warehouses can also be put on a suspend and resume schedule. For resource monitors specifically, see the resource monitor page.