What Do Airflow, Fivetran and Your BI Tools Cost in Snowflake? (2026)

There is no ready-made report for Snowflake cost by tool, but most tools leave a trail you can price. Each one connects as a user, runs on a warehouse, and may label its queries. Tableau and Power BI support a query tag, Looker and dbt add a SQL comment, Airflow adds no query tag to SQL tasks unless you set one, and Fivetran documents neither. So give each tool its own user, then group QUERY_ATTRIBUTION_HISTORY by tool. Every fact and figure in this guide was checked against Snowflake’s documentation.

This article is part of our guide to Snowflake cost monitoring. We checked each tool’s behavior against that vendor’s own documentation, and the Airflow details against its released source code.

Can Snowflake show cost by tool?

Not directly. Snowflake records the user, role and warehouse of each query, and QUERY_ATTRIBUTION_HISTORY attributes warehouse credits to most of them. No column in QUERY_HISTORY names the tool. The SESSIONS view names the driver, such as JDBC, which several tools share. So you identify a tool by its user, its warehouse, or the tag or comment it adds.

Each handle has a view behind it. USER_NAME is in QUERY_ATTRIBUTION_HISTORY, and ROLE_NAME is in QUERY_HISTORY. A warehouse’s full compute cost, idle time included, is in WAREHOUSE_METERING_HISTORY. A QUERY_TAG is a session parameter of up to 2,000 characters.

In SESSIONS, the CLIENT_APPLICATION_ID column names the Snowflake-provided client, for example “JDBC 3.8.7”, not the tool built on it. Fivetran and Looker, for example, both connect through the Snowflake JDBC driver. Airflow’s hook also sends application=AIRFLOW on every connection (provider 6.20.0). Snowflake does not document where that name appears, so check SESSIONS first.

For the user, role and warehouse views, see our guide to Snowflake cost by user, role and warehouse.

What does each tool leave behind in Snowflake?

Tableau adds a query tag on its own, and Microsoft lists query tag support for Power BI. Looker and dbt append a SQL comment, per their documentation. Airflow adds no query tag or SQL comment to ordinary SQL tasks unless you set a tag. Fivetran documents no tag or comment, so you find it by its user and warehouse.

Looker’s and dbt’s documentation say the comment goes at the end of the SQL, but no Snowflake page says QUERY_TEXT keeps it. Before relying on it, run one query from that tool and check that the comment appears in QUERY_TEXT.

How do you give each tool its own user and warehouse?

Create one service user per tool, then group QUERY_ATTRIBUTION_HISTORY by user. That separates tools with no parsing at all. A dedicated warehouse per tool shows the full compute bill, idle time included, but it can cost more than sharing one. You can also set a default QUERY_TAG on each user.

Snowflake’s CREATE USER reference defines TYPE = SERVICE for an application that connects without human intervention. A SERVICE user cannot sign in with a password, so the tool needs key-pair or another non-password method. A new user also needs its own grants, and the objects it creates belong to its role, so test with a copy of the connection and keep the old user until the new one works. This query shows attributed credits for each user:

-- Attributed compute credits by user, last 30 days. View lags up to 8 hours. Needs SNOWFLAKE.USAGE_VIEWER or GOVERNANCE_VIEWER.
SELECT user_name,
       ROUND(SUM(credits_attributed_compute), 2) AS credits,
       COUNT(*)                                  AS queries
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ATTRIBUTION_HISTORY
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY user_name
ORDER BY credits DESC;

Fivetran’s setup guide says an exclusive warehouse means you pay to run it, while a shared one can lower that cost. A dedicated warehouse can also take a resource monitor; our guide to Snowflake budgets vs resource monitors explains when to use each.

A default tag on the user applies to tools that set none of their own. A tag the tool sets itself, or an ALTER SESSION, replaces it for that session. Test it with your own tools, because some send their own tag:

-- Sets a default tag on a user. Needs a role that can alter the user, typically SECURITYADMIN. Reverse it with ALTER USER fivetran_user UNSET QUERY_TAG. Try it on a test user first.
ALTER USER fivetran_user SET QUERY_TAG = 'tool=fivetran';

How do you tag Airflow queries by DAG and task?

Airflow’s Snowflake provider sets no query tag on ordinary SQL tasks, so you set one yourself. Pass QUERY_TAG in session_parameters through the operator’s hook_params, and put the DAG and task IDs in the tag with Jinja templates. Then you can group QUERY_ATTRIBUTION_HISTORY by DAG and task.

from airflow.providers.common.sql.operators.sql import SQLExecuteQueryOperator

# Inside a DAG definition. Tags every query this task runs as airflow:<dag_id>:<task_id>
SQLExecuteQueryOperator(
    task_id="build_orders",
    conn_id="snowflake_default",
    sql="sql/build_orders.sql",
    hook_params={
        "session_parameters": {
            "QUERY_TAG": "airflow:{{ dag.dag_id }}:{{ task.task_id }}"
        }
    },
)

These points hold for Snowflake provider version 6.20.0:

• Use SQLExecuteQueryOperator. The provider removed SnowflakeOperator in version 6.0.0.
• Templates work in the tag. hook_params has been a templated field since version 1.12.0 of the common SQL provider, and Airflow’s templater renders values inside a dictionary.
• The hook wins over the connection. A session_parameters value passed on the hook replaces the one in the connection’s Extra field instead of merging with it.
• Two operators ignore the setting. SnowflakeSqlApiOperator and SnowflakeNotebookOperator, which builds on it, accept session_parameters, but the hook builds the API request without it. The Snowflake check operators do use it.
• Snowpark sessions are the exception. The hook tags them with the Airflow and provider versions.

For tag basics, see our Snowflake query tags guide.

How do you find Fivetran’s cost in Snowflake?

Fivetran documents no query tag or SQL comment, so use its user and its warehouse. Its Snowflake setup script creates FIVETRAN_USER and, by default, an exclusive FIVETRAN_WAREHOUSE. If Fivetran has its own warehouse, sum that warehouse’s metered credits. If it shares one, filter QUERY_ATTRIBUTION_HISTORY by the Fivetran user.

The script creates the warehouse as X-Small with a 60-second auto-suspend. This query returns the dedicated warehouse’s daily compute credits, so use your own names if you changed the defaults:

-- Daily compute credits for Fivetran's warehouse, last 30 days. View lags up to 3 hours. Needs SNOWFLAKE.USAGE_VIEWER.
SELECT DATE_TRUNC('day', start_time)          AS day,
       ROUND(SUM(credits_used_compute), 2)    AS credits
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE warehouse_name = 'FIVETRAN_WAREHOUSE'
  AND start_time >= DATEADD(day, -30, CURRENT_DATE())
GROUP BY 1
ORDER BY 1;

Since July 2025, Fivetran has been rolling out a choice of Snowflake warehouse for each connection, according to its changelog. A warehouse per connection would show cost per connection, if nothing else uses it.

Keep two bills apart. Fivetran bills by Monthly Active Rows, while Snowflake bills separately for the compute that Fivetran’s loads use. Our Fivetran spend analysis covers the Fivetran side.

Does Tableau tag its Snowflake queries?

Yes. Tableau Cloud and recent Tableau Server releases tag Snowflake queries by default. The tag is a session query tag, so it appears in QUERY_TAG, not in the SQL text. It carries IDs for the site, the workbook, worksheet or dashboard, and the user. Tableau does not document the tag’s format, so match on a service user instead.

Tableau’s query tagging page lists the gaps to expect:

• Names are missing. The tag holds IDs, not workbook names. Tableau Server adds the user name, but Tableau Cloud does not.
• Some queries carry no workbook ID or user. Ask Data, accelerated workbooks and Tableau Prep may carry no workbook ID. Backgrounder jobs carry no user.
• Administrators can turn the tag off on Server. Check that it is present, and note that the page does not cover Tableau Desktop.

What does Looker add to its queries?

Looker appends a context comment to queries from Explores, SQL Runner, the API and filter suggestions. On Snowflake the comment goes at the end of the query, where Looker says it shows in your database query logs. It holds the Looker user ID and a history slug, not a dashboard. So Snowflake’s data alone gives cost per Looker user.

The comment starts with -- Looker Query Context and holds a user ID, a history slug and the instance number. Looker appends it on Snowflake because, in Looker’s words, Snowflake removes leading comments. The page lists only four query sources, so other queries, such as persistent derived table builds, may carry no comment. A separate Looker connection user would count those queries as Looker, but check its grants and who owns any persistent derived tables first. A SERVICE user also cannot sign in with a password, so test with a copy of the connection and keep the old user until the new one works.

One cost to watch: with persistent derived tables, Looker checks for regeneration every five minutes by default, and Looker says this keeps Snowflake warehouses active.

Does Power BI tag its Snowflake queries?

Microsoft’s release notes for the Power BI connector for Snowflake list support for a Snowflake query tag since April 2025. The documented example names a host but no report or semantic model. Microsoft documents no setting for your own tag, so give Power BI its own warehouse or role.

Microsoft’s connector page gives this example tag: {"PowerQuery":true,"Host":"PBI_SemanticModel_MWC","HostContext":"PowerBIPremium-DirectQuery"}. The page does not say which connections send the tag, so check a sample query.

How does dbt label its queries?

dbt adds a JSON comment with the model’s node ID to every query, and its documentation says the comment goes at the end of the statement on Snowflake. It also supports query tags at three levels: your profile, a model or folder setting, and a macro. Match the comment in QUERY_TEXT after checking it, or group by QUERY_TAG.

If you customize dbt’s query-comment, set append: true so the comment stays at the end, because, as dbt’s docs note, Snowflake removes leading comments. Our guide to reducing the Snowflake cost of dbt models joins the comment to attributed credits for each model.

How do you total Snowflake credits by tool in one query?

Join QUERY_ATTRIBUTION_HISTORY to QUERY_HISTORY on QUERY_ID. Then label each query with a CASE expression that checks the SQL comment, the query tag and the user, and sum CREDITS_ATTRIBUTED_COMPUTE by label. The result is attributed compute credits, so it leaves out idle time and some other costs.

Change the user names to your own, and the dbt string if you changed dbt’s comment format. The first matching line wins. The dbt and Looker lines need the QUERY_TEXT check described above first. Reading both views needs the SNOWFLAKE database role GOVERNANCE_VIEWER or IMPORTED PRIVILEGES on the SNOWFLAKE database, which ACCOUNTADMIN can grant, according to Snowflake’s Account Usage roles. USAGE_VIEWER covers QUERY_ATTRIBUTION_HISTORY only.

-- Attributed compute credits by tool, last 30 days. QUERY_ATTRIBUTION_HISTORY lags up to 8 hours. Needs SNOWFLAKE.GOVERNANCE_VIEWER, which covers both views. Check the dbt and Looker lines first.
SELECT
  CASE
    WHEN qh.query_text ILIKE '%"app": "dbt"%'           THEN 'dbt'
    WHEN qh.query_text ILIKE '%Looker Query Context%'   THEN 'Looker'
    WHEN qh.query_tag  ILIKE '%PowerQuery%'             THEN 'Power BI'
    WHEN qh.query_tag  ILIKE 'airflow:%'                THEN 'Airflow'
    WHEN qh.query_tag  ILIKE '%airflow_version%'        THEN 'Airflow'
    WHEN qh.user_name  = 'FIVETRAN_USER'                THEN 'Fivetran'
    WHEN qh.user_name  = 'TABLEAU_SVC'                  THEN 'Tableau'
    ELSE 'Other'
  END                                          AS tool,
  ROUND(SUM(qa.credits_attributed_compute), 2)                      AS credits,
  ROUND(SUM(COALESCE(qa.credits_used_query_acceleration, 0)), 2)   AS qas_credits,
  COUNT(*)                                                          AS queries
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ATTRIBUTION_HISTORY qa
JOIN SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY qh
  ON qh.query_id = qa.query_id
WHERE qa.start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND qh.start_time >= DATEADD(day, -31, CURRENT_TIMESTAMP())
GROUP BY 1
ORDER BY credits DESC;

Try 7 days first on a small warehouse, because filtering QUERY_TEXT scans a lot of text.

What does the per-tool number leave out?

It leaves out warehouse idle time, queries of about 100 milliseconds or less, cloud services, serverless features, storage, data transfer and AI tokens. It also lags by up to eight hours, and Adaptive Warehouses have no rows in the view. For a tool with its own warehouse, the metering view gives the full compute figure.

Query Acceleration has its own column, shown above as qas_credits. Snowflake points to QUERY_METERING_HISTORY for Adaptive Warehouses. Snowflake’s guide to attributing cost says user-level data comes from one account at a time. Also, QUERY_HISTORY cuts QUERY_TEXT at 100K characters, so a long statement can lose a trailing comment.

How Seemore helps with cost by tool

Tags and comments cover only the tools that add them, and the views behind this guide run hours behind. The Seemore platform attributes cost by job, user, domain and data product. You can also ask Seemore Assistant about your environment in plain language instead of writing the SQL above.