In Snowflake, what actually consumes credits, and what is billed outside the credit meter?

## What a credit is A credit is Snowflake's unit of compute consumption. It is not a currency: the dollar value of a credit depends on edition, cloud provider and region, and it changes over time — quoting a rate from memory in an interview is a mistake. What you are expected to know is *which activities burn credits* and *what the meter is measuring*. ## Virtual warehouse compute — the dominant line item A virtual warehouse is a cluster of compute nodes Snowflake starts on your behalf. While that cluster is in the `running` state it consumes credits **per second**, whether it is executing a query or sitting idle with an open session. Each time a warehouse starts or resumes there is a **60-second minimum** charge, so a warehouse that resumes for a two-second query still bills a full minute. The per-hour credit rate scales with warehouse size, and a multi-cluster warehouse bills each running cluster. The crucial consequence: **the meter is time-based, not data-based**. Halving the bytes a query scans saves money only if it shortens the seconds the warehouse spends running or lets it suspend sooner. This is the opposite of BigQuery's on-demand model, where the bill is literally bytes processed, and interviewers probe the difference deliberately. ## Cloud services The cloud services layer — optimizer, metadata store, authentication, access control, the result cache — runs on Snowflake-managed compute and consumes credits too. Snowflake applies a daily adjustment: cloud-services credits are billed only to the extent that a day's cloud-services consumption exceeds **10%** of that day's virtual-warehouse credits. Most workloads never pay for it. The ones that do are metadata-heavy and compute-light: floods of `SHOW` commands and `INFORMATION_SCHEMA` queries, huge numbers of tiny single-row DML statements, or heavy use of result-cache-only reads with almost no warehouse activity to earn the allowance. ## Serverless features Several features run on Snowflake-managed compute rather than on your warehouse, and each has its own credit rate: Snowpipe and Snowpipe Streaming, automatic clustering, materialized-view maintenance, search-optimization maintenance, replication, and tasks configured to run serverless. These bill independently of any warehouse, which is why a bill can rise on a weekend when nobody is querying. They are also the credits that resource monitors do **not** stop, so they need their own monitoring. ## Storage and data transfer Storage is billed monthly on **average daily compressed bytes**, at a per-TB rate, outside the credit meter. It covers table data plus Time Travel versions, Fail-safe copies, clones' unique bytes, and files sitting in internal stages — which is why a table that looks small can bill much larger after heavy churn with a long `DATA_RETENTION_TIME_IN_DAYS`. Data transfer (egress to another region or cloud) is billed separately again. On a typical account, storage is a small fraction of spend and compute dominates. ## Seeing where the credits went The `SNOWFLAKE.ACCOUNT_USAGE` schema is where you answer "who spent it": ```sql SELECT warehouse_name, SUM(credits_used) AS credits FROM snowflake.account_usage.warehouse_metering_history WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP()) GROUP BY 1 ORDER BY credits DESC; ``` `WAREHOUSE_METERING_HISTORY` gives credits per warehouse per hour; `METERING_DAILY_HISTORY` breaks the whole account down by credit type including serverless; `QUERY_HISTORY` tells you which statements ran on which warehouse; `TABLE_STORAGE_METRICS` and `STORAGE_USAGE` cover bytes. Recent Snowflake versions add `QUERY_ATTRIBUTION_HISTORY` for per-query credit attribution, which is the closest thing to a per-query price tag. All of these views lag real time by a latency window, so same-hour reconciliation is not possible from them — `INFORMATION_SCHEMA` table functions are the low-latency alternative. ## The tuning implication Because cost is credit-rate × seconds-running, the levers are: keep warehouses from idling, keep queries short, and let cheap layers (result cache, metadata-only answers) serve work without starting compute at all. "Scan fewer bytes" is a means to that end, not the billing unit itself.