Snowflake cost attribution assigns shared platform costs to the teams, pipelines, and queries that generated them.
A warehouse called ANALYTICS_WH may support four teams. Finance can run month-end models, the growth team can run dashboards, a dbt job can execute every hour, and a data scientist can run occasional large queries. If the warehouse consumes 7,840 credits in one month, the invoice reports the total without allocating it among the four teams.
WAREHOUSE_METERING_HISTORY in ACCOUNT_USAGE reports credits consumed by each warehouse per hour. This level of detail is sufficient when each warehouse has one owner. A shared warehouse combines all sessions into a single meter, so its record does not identify the teams responsible for consumption. Accounts spending $200K or more a year commonly operate at least a few shared warehouses.
Separate warehouses provide direct attribution when each team or workload receives a dedicated resource, such as FINANCE_WH, GROWTH_WH, or DBT_WH. The warehouse name identifies the owner without additional tooling. This approach reduces pooling efficiency because ten small warehouses can idle and resume on separate schedules, while a busy shared warehouse distributes idle time across more users. The cost trade-off depends on whether workloads are steady and separable or spiky and overlapping.
Object tags add ownership metadata to warehouses and databases, including keys such as cost_center. TAG_REFERENCES can be joined with metering and query history to aggregate costs by tag. The QUERY_TAG session parameter labels queries from a session or scheduled job, allowing a dbt run to identify all of its statements. Object tags on a shared warehouse describe the warehouse rather than the teams using it, while QUERY_TAG provides query-level detail only when sessions set it consistently.
QUERY_ATTRIBUTION_HISTORY in ACCOUNT_USAGE assigns compute credits to individual queries through CREDITS_ATTRIBUTED_COMPUTE. Each row also includes USER_NAME, WAREHOUSE_NAME, and QUERY_TAG, allowing the 7,840-credit example to be aggregated by user, role, or query tag.
The view excludes warehouse idle time, cloud services, storage, data transfer, and serverless costs. Queries under roughly 100 milliseconds are too short to attribute. Data can arrive with up to six hours of latency, and historical coverage begins in mid-August 2024. When a warehouse remains active between query bursts, a separate allocation rule is required for the difference between attributed and metered credits.
The following query produces a per-user and per-tag breakdown:
-- credits attributed to each user and query tag on a shared warehouse, last 30 days
select user_name, query_tag, sum(credits_attributed_compute) as credits
from snowflake.account_usage.query_attribution_history
where warehouse_name = 'ANALYTICS_WH'
and start_time >= dateadd('day', -30, current_timestamp())
group by user_name, query_tag
order by credits desc;
Reader accounts allow data sharing with consumers outside the Snowflake customer base. The provider creates, owns, and pays for the account, including compute used by the consumer. Warehouses in a reader account can consume an unlimited number of credits charged to the provider. Resource monitors can limit usage on reader-account warehouses, while READER_ACCOUNT_USAGE views in the SNOWFLAKE shared database report consumption for each account. Attribution models generally assign these credits to the sharing program or external customer rather than an internal cost center.
Showback reports each team's cost without changing its budget, while chargeback debits the cost from the team's budget. Showback can be implemented before financial allocation and may change behavior once engineers can see their usage. Both methods depend on consistent tags, per-query attribution, and separate treatment of reader-account usage.
No. It covers query compute and leaves out idle time, cloud services, storage, and serverless costs, so the attributed total sits below the metered total. You will want an allocation rule, usually proportional to attributed usage, to spread idle and overhead credits back to teams. Confirm the current exclusions in the Snowflake docs before you build the logic.
You do, as the provider. The consumer pays nothing and signs nothing. Every credit a user burns in a reader account is charged to your account, which is why resource monitors and the READER_ACCOUNT_USAGE views matter for anyone running a sharing program at scale.
Not necessarily. Per-query attribution plus consistent query tags can split a shared warehouse without breaking pooling. Separate warehouses give simpler books at some cost to efficiency, so the answer turns on how spiky and overlapping your workloads are.
Turn on showback with the data already in hand. Pull QUERY_ATTRIBUTION_HISTORY grouped by user and query tag, layer in WAREHOUSE_METERING_HISTORY for the idle remainder, and send each team its number before touching any budget.