Why Every Snowflake Developer Should Use QUERY_TAG

One of the most underutilized features in Snowflake is QUERY_TAG. While it takes only seconds to implement, it can dramatically improve monitoring, troubleshooting, cost attribution, and performance analysis.

What is QUERY_TAG?

QUERY_TAG allows you to attach custom metadata to queries executed in Snowflake. This metadata is stored in query history and can be searched, filtered, and reported on later.

Think of it as adding a label to your SQL so you can answer questions such as:

• Which application generated this query?
• Which ETL process consumed the most credits?
• Which release introduced a performance issue?
• Which developer executed a problematic query?

Setting a QUERY_TAG

You can set a query tag for your current session:

ALTER SESSION SET QUERY_TAG = 'daily_sales_etl';

Any queries executed afterwards will inherit this tag.

Example:

ALTER SESSION SET QUERY_TAG = 'daily_sales_etl';

INSERT INTO SALES_FACT
SELECT *
FROM STG_SALES;

Using Structured Tags

A simple tag works well, but structured tags provide much more value.

ALTER SESSION SET QUERY_TAG =
'project=finance|process=daily_load|env=prod|version=1.3';

This allows teams to quickly identify workloads and releases when reviewing query history.

Changing Tags During Execution

You can update the tag throughout a process:

ALTER SESSION SET QUERY_TAG = 'customer_load_extract';

SELECT * FROM STG_CUSTOMERS;

ALTER SESSION SET QUERY_TAG = 'customer_load_transform';

MERGE INTO DIM_CUSTOMER
USING STG_CUSTOMERS;

This makes it easier to understand which stage of a pipeline consumed resources.

Finding Queries by Tag

Query history can be searched using the QUERY_TAG column.

SELECT
    QUERY_ID,
    QUERY_TEXT,
    TOTAL_ELAPSED_TIME,
    QUERY_TAG
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE QUERY_TAG LIKE '%daily_sales_etl%';

Making QUERY_TAG Part of Your Engineering Standards

Many teams experiment with query tags but fail to gain meaningful value because developers apply them inconsistently.

The real power of QUERY_TAG comes when tagging is automated and enforced across your data platform.

Rather than relying on individual developers to remember to set tags manually, configure your orchestration and transformation tools to apply them automatically.

Examples include:

• Airflow DAGs
• dbt models and jobs
• Matillion pipelines
• Informatica workflows
• Python ETL processes
• CI/CD deployment pipelines

When implemented correctly, every query executed in Snowflake can be traced back to:

• The application
• The business process
• The environment
• The deployment version
• The owning team

Example: Python Connector

conn.cursor().execute("""
ALTER SESSION SET QUERY_TAG =
'project=finance|process=daily_load|env=prod|version=2.1'
""")

All subsequent queries executed through that connection will automatically inherit the tag.

Example: dbt

You can configure query tags at the project or model level:

query-comment:
  comment: "{{ target.name }}|{{ node.name }}"
  append: true

This enables Snowflake administrators to quickly identify which dbt model generated a query.

Example: Cost Attribution

Want to know which process consumed the most warehouse resources?

SELECT
    QUERY_TAG,
    COUNT(*) AS QUERY_COUNT,
    SUM(TOTAL_ELAPSED_TIME)/1000 AS TOTAL_SECONDS
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE START_TIME >= DATEADD(DAY,-7,CURRENT_TIMESTAMP())
GROUP BY QUERY_TAG
ORDER BY TOTAL_SECONDS DESC;

This provides immediate visibility into the workloads driving platform consumption.

Best Practices

1. Define a standard tagging convention.
2. Automate tagging wherever possible.
3. Include environment information (DEV, TEST, PROD).
4. Include application or process names.
5. Include deployment or release versions.
6. Avoid free-form tags that become inconsistent over time.
7. Periodically audit query history to ensure tags are being applied.

Recommended format:

project=sales|process=daily_load|env=prod|version=2.1

Final Thoughts

Most Snowflake teams focus heavily on warehouses, clustering, caching, and query tuning. Yet many struggle to answer a simple question:

“What generated this query?”

A consistent QUERY_TAG strategy solves that problem immediately.

With only a few lines of configuration, engineering teams gain better observability, faster troubleshooting, improved cost attribution, and clearer ownership of workloads across the entire Snowflake platform.

If your organization isn’t using QUERY_TAG today, it’s one of the highest-value, lowest-effort improvements you can make.