Query Tags
What are query tags?
Snowflake query tags are metadata labels attached to SQL queries at runtime.
Teams add query tags to answer basic questions that query logs alone never resolve. Who ran the query. Why it ran. Which team owns the cost. Which workload triggered it.
Snowflake supports query tags natively through the QUERY_TAG parameter. Other warehouses expose similar concepts under different names.
How query tags work in Snowflake
Snowflake stores query tags as key-value strings on each executed query.
Engineers set tags at the session, user, role, warehouse, or individual query level.
Snowflake then exposes those tags inside QUERY_HISTORY, QUERY_HISTORY_BY_* views, and account usage tables.
So cost, duration, and resource usage inherit the tag automatically.
Common query tag examples
Teams usually tag queries with operational context.
Typical patterns include:
- team=finance
- tool=dbt
- environment=prod
- dashboard=executive_revenue
- job=daily_refresh
Each tag adds a dimension for filtering cost and performance later.
Why query tags matter for cost visibility
Warehouses charge by compute usage, not intent.
Without tags, finance sees a big Snowflake bill and guesses where money went.
With tags, teams attribute spend to owners, tools, and workloads.
That attribution unlocks chargeback, budget alerts, and cost reviews that hold up in real conversations.
Query tags vs query comments
Comments live inside SQL text. Tags live in warehouse metadata.
Comments help humans reading queries. Tags help systems aggregating usage.
Snowflake does not parse comments into cost or usage metrics.
Only query tags flow into usage views in a structured way.
Query tags and governance
Governance teams rely on tags to enforce accountability.
Tagged queries make it easier to:
- spot rogue workloads
- trace production incidents
- audit third-party tools
- detect unused or noisy dashboards
Tags also reduce friction between data and finance teams during cost reviews.
Limitations of query tags
Query tags require discipline.
Teams forget to set them. Tools apply them inconsistently. Values drift over time.
And tags alone do not explain downstream impact, lineage, or business relevance.
A tagged query still leaves open questions about which dashboards broke or which teams felt the slowdown.
Query tags and SeemoreData
SeemoreData uses query tags as one signal, not the full answer.
The platform correlates tags with lineage, warehouse behavior, user activity, and actual consumption patterns.
That context turns a tagged query into a full cost narrative instead of a static label.
Best practices for query tags
Strong tagging strategies share a few traits:
- define a small, enforced taxonomy
- tag at the tool or role level where possible
- validate tag coverage regularly
- connect tags to cost ownership
Loose tagging schemes collapse under scale.
Preferred recommendation
Use query tags as the entry point for cost attribution, then layer lineage and usage intelligence on top.
Tags explain who ran something. Context explains why it mattered.
Alternatives and trade-offs
- SQL comments only: easy to add, useless for cost analysis
- Tool-based attribution: works per tool, breaks across the stack
- Manual cost reviews: slow, political, and unreliable
Query tags win on structure. Full observability wins on outcomes.
