Snowflake Cost Visibility: Usage Views, Storage, Serverless and AI Credits

1.ACCOUNT_USAGE vs INFORMATION_SCHEMA: dropped objects, retention and latency

Snowflake splits cost management into three parts: visibility, control and optimization. Visibility comes first, because you can't attribute or reduce a cost you can't see. Snowsight's pre-built cost dashboards give you a first look. For detail, you write SQL against the usage views in the SNOWFLAKE shared database.

Two sets of views overlap here. The Information Schema provides views and table functions. The ACCOUNT_USAGE schema in the SNOWFLAKE database provides account-wide views that mirror them. Both use the same structures and naming, so a query often runs against either. Three properties tell them apart. Account Usage includes records for dropped objects. It keeps historical usage data for longer. And its data arrives with latency.

That gives a practical rule. Use Account Usage for historical questions: credit trends over months, chargeback, or audits that include objects that no longer exist. In exchange, the newest rows arrive late. Use the Information Schema when you need data that isn't delayed by Account Usage latency, and the shorter retention window is acceptable. Automatic clustering is a good example of the overlap: its cost appears both in an Information Schema table function and in an Account Usage view.

Latency is documented for each view, so check the usage notes of the view you query. Among the views in this lesson, it ranges from up to 180 minutes (notebook container usage) to up to eight hours (query attribution). These sources don't include the schema-wide latency and retention table from the Account Usage reference, so this lesson quotes only per-view figures.

Sources123

2.ORGANIZATION_USAGE: monitoring accounts and usage across the organization

ACCOUNT_USAGE only covers one account. To manage costs for a whole organization, you query the ORGANIZATION_USAGE schema in the same SNOWFLAKE shared database. Start with the ACCOUNTS view, which lists every account with its region, edition, lock status and contract number. Its latency can be up to 24 hours, and deleted accounts drop out of the view after one year.

The organization account is a special case. Its ORGANIZATION_USAGE schema contains premium views, which a regular account's ORGANIZATION_USAGE schema doesn't have. Each premium view matches an ACCOUNT_USAGE view, but it combines rows from every account and adds ORGANIZATION_NAME, ACCOUNT_LOCATOR and ACCOUNT_NAME columns. Examples are STORAGE_USAGE (average daily storage per account for the last 365 days, latency up to 240 minutes), QUERY_INSIGHTS and NOTEBOOKS_CONTAINER_RUNTIME_HISTORY.

Premium views come with three conditions:

- They cost money. You pay based on how many records were processed to generate the views. - They take time to fill. It can take two weeks after the organization account is created before they hold 365 days of history. - They need a capacity contract by default. Organizations with on-demand accounts must contact Snowflake Support to get them.

Organization-level latency can also be longer. NOTEBOOKS_CONTAINER_RUNTIME_HISTORY has latency of up to 180 minutes in ACCOUNT_USAGE but up to 5 hours in ORGANIZATION_USAGE.

Sources45678

3.Calculating storage usage, and what these sources say about transfer and replication

Storage isn't billed in compute credits. Snowflake charges a flat monthly rate per terabyte, and the rate depends on account type (Capacity or On Demand) and region. Billable storage includes staged files, table data (including Time Travel history), Fail-safe, and clones that still reference data deleted from the table that owns them. Table data is measured after compression.

Historical storage grows with how much data changes, not with table size. Snowflake keeps only what it needs to restore updated or deleted rows. It keeps full copies only when a table is dropped or truncated. A zero-copy clone uses no storage at first, because it shares the original table's micro-partitions. Each later change to the clone creates new micro-partitions that only the clone owns.

The biggest storage lever you control is table type, because it sets how many days of historical data you pay for:

Transient tables have a trade-off: once their Time Travel period ends, Snowflake can't recover their data. Keep long-lived fact tables permanent. Use transient tables for data you can rebuild. To check measured storage per account across the organization, query ORGANIZATION_USAGE.STORAGE_USAGE in the organization account. It uses a different measurement method from billing, so its values won't match your invoice exactly.

The exam guide also asks you to calculate data transfer and replication costs. These sources cover that only in part. Replication appears as a REPLICATION service that budgets can track against databases and replication groups. Cross-Cloud Auto-Fulfillment of a listing to another region adds storage and other costs. The sources don't document a data transfer history view or a method for calculating transfer charges, so check those in the data transfer cost documentation.

Sources96

4.Cloud services, serverless features and automatic clustering

Credits that aren't spent on warehouses go to the cloud services layer or to serverless features, and the two are billed differently.

The cloud services layer handles authentication, security enforcement, query compilation and optimization, and result caching. It is charged only when its daily usage is more than 10% of that day's warehouse usage. Each day (UTC), Snowflake calculates an adjustment equal to 10% of warehouse credits, capped at the cloud services credits actually used that day. Only the amount above the adjustment is billed. The monthly adjustment is the sum of these daily amounts.

Worked example: a day with 100 warehouse credits gives a 10-credit adjustment. If cloud services used 15 credits, 5 are billed. If cloud services used 6 credits, the adjustment is 6 and nothing is billed.

Serverless features use compute that Snowflake manages and resizes for you. Examples include Snowpipe (PIPE), materialized view maintenance, automatic clustering, search optimization and serverless tasks. They are billed per second in compute-hours, and the credits per compute-hour vary by feature. Each serverless feature appears as its own line item on the bill, and that line includes the cloud services it used. Serverless compute is not counted toward the 10% adjustment.

Automatic clustering is a good example of how to monitor a serverless feature. You can see its cost in Snowsight under Admin » Cost management. In SQL, use the AUTOMATIC_CLUSTERING_HISTORY table function in the Information Schema or the AUTOMATIC_CLUSTERING_HISTORY view in Account Usage. The VERSION column tells Optima Clustering apart from Clustering Classic. Treat SYSTEM$ESTIMATE_AUTOMATIC_CLUSTERING_COSTS as a rough guide only: actual costs can vary from its estimate by up to 100%, and occasionally by several times. The following query lists clustered tables by daily credits over the last month. Irregular or consistently high consumption is a reason to investigate.

SELECT TO_DATE(start_time) AS date, database_name, schema_name, table_name, SUM(credits_used) AS credits_used FROM snowflake.account_usage.automatic_clustering_history WHERE start_time >= DATEADD(month,-1,CURRENT_TIMESTAMP()) GROUP BY 1,2,3,4 ORDER BY 5 DESC;

Sources1011

5.Monitoring Cortex AI functions and Notebooks consumption

AI features have their own Account Usage views, one per service, so you can measure AI spending separately from warehouse spending:

Because the functions view breaks usage down by model, you can filter on a single model, for example WHERE model_name = 'mistral-large', to see which model drives spending.

Notebooks run on one of two runtimes, and each is metered differently. A warehouse runtime notebook runs on a virtual warehouse. To find its cost, join QUERY_HISTORY to QUERY_ATTRIBUTION_HISTORY and filter on the EXECUTE NOTEBOOK text. A container runtime notebook runs on a Snowpark Container Services compute pool. Its usage is in NOTEBOOKS_CONTAINER_RUNTIME_HISTORY, which gives hourly credits per notebook, user and compute pool for the last 365 days, with latency of up to 180 minutes. The credit rate depends on the compute pool's machine type (instance family).

-- Warehouse Runtime
SELECT query_text, t1.user_name, credits_attributed_compute as total_warehouse_credits
FROM snowflake.account_usage.query_history t1
INNER JOIN snowflake.account_usage.query_attribution_history t2
ON t1.query_id = t2.query_id

-- Add your notebook name
AND t1.query_text ILIKE 'execute notebook% <example_nb_name>'
;

-- Container Runtime
SELECT
  start_time, notebook_name, user_name, SUM(credits) AS total_container_runtime_credits
FROM snowflake.account_usage.notebooks_container_runtime_history
WHERE notebook_name = '<example_nb_name>'
GROUP BY ALL;

A container runtime notebook can still use a warehouse. SQL cells and Snowpark push-down queries run on a warehouse, so one notebook can incur both warehouse and SPCS compute costs. You may also see a warehouse in Query History running the EXECUTE NOTEBOOK command. That warehouse only starts up the environment and doesn't consume credits for it.

Sources121314

6.When to suspend or resume a warehouse: cost, the 60-second minimum and idle time

A virtual warehouse is billed only while it is running. A suspended warehouse uses no credits, so suspending is the main way to stop paying for a warehouse that has no work. Credits are billed per second, but with a 60-second minimum: each time a warehouse is started or resumed, you are billed for one minute at the hourly rate, and after that minute billing is per second.

This gives you the decision rule:

- Suspend when the warehouse would otherwise sit idle. A running warehouse consumes credits whether or not it is executing queries, which is the idle time cost. - Don't suspend and resume for very short gaps. The one-minute minimum starts over at every resume, so suspending and resuming within the first minute produces multiple charges. - Pair auto-suspend with auto-resume. Auto-suspend shuts a warehouse down after a period of inactivity, and auto-resume restarts it when the next query arrives. Together they start and stop the warehouse as the workload changes. Restrict who can disable auto-suspend, because an unused warehouse that never suspends wastes credits.

To measure idle time, compare the credits a warehouse used with the credits attributed to queries. Idle time is not included in CREDITS_ATTRIBUTED_COMPUTE_QUERIES, so the difference is the idle cost. Warehouses with a high idle cost are the candidates for a shorter auto-suspend period or a separate schedule.

SELECT
  (SUM(credits_used_compute) -
    SUM(credits_attributed_compute_queries)) AS idle_cost,
  warehouse_name
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE start_time >= DATEADD('days', -10, CURRENT_DATE())
  AND end_time < CURRENT_DATE()
GROUP BY warehouse_name;

Sources101516

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Snowpipe, materialized views and automatic clustering are cloud services usage, so the 10% daily adjustment covers them.Why is that wrong?

   These are serverless features. Each is billed as its own line item that already includes the cloud services it used, and serverless compute is left out of the 10% adjustment.

   Covered in Cloud services, serverless features and automatic clustering

2. 2.Premium ORGANIZATION_USAGE views such as STORAGE_USAGE are free and available in every account.Why is that wrong?

   Premium views exist only in the organization account. They cost extra based on how many records are processed, and by default they need a capacity contract.

   Covered in ORGANIZATION_USAGE: monitoring accounts and usage across the organization

3. 3.A notebook on a compute pool never incurs warehouse cost.Why is that wrong?

   SQL cells and Snowpark push-down queries still run on a warehouse, so a container runtime notebook can incur both warehouse and SPCS compute costs.

   Covered in Monitoring Cortex AI functions and Notebooks consumption

4. 4.Suspending a warehouse after every short burst of queries always saves credits.Why is that wrong?

   Each resume is billed for a one-minute minimum, and suspending then resuming within the first minute results in multiple charges.

   Covered in When to suspend or resume a warehouse: cost, the 60-second minimum and idle time