Databricks SQL logs key attributes of every query automatically: who ran it, on which warehouse, and from which tool. But that's often not enough.
When a Power BI query is running slow, you know it came from Power BI, but not which dashboard to fix. When costs spike, you can see which users ran queries, but not which cost center or project to charge. The missing piece is custom context, and that's exactly what Query Tags adds.
Today, we're introducing Query Tags in Public Preview. Query Tags let you attach business context as multiple key-value pairs to every SQL execution, and query it all through system tables with standard SQL — or just by asking Genie. Query Tags are also visible in the Query Profile UI (search support in the Query History UI is coming soon).
Query Tags have already seen strong adoption, with hundreds of customers tagging millions of queries weekly.
With Query Tags, you attach custom key-value pairs (e.g. “project” : “finance_planning”) to each SQL execution. These tags travel with the query and are recorded in the Query History System Table, making them available for grouping, filtering, and analyzing workloads.
Tags add value across three scenarios:
Let’s go deeper into these scenarios.
Queries from dbt, Power BI, and Tableau flow into your warehouse — but without tags, they're untraceable beyond a user ID and which tool they came from. These tools solve this by injecting Query Tags automatically, with no manual tagging required.
dbt automatically tags every query with the model name, core version, adapter version, and materialization type. If a dbt model suddenly regresses in performance, you can pinpoint exactly which model, which version, and when:
Staff engineering leads Dipesh Bhundia and Dave Couse at ASOS added:
"Without having to configure anything, we can map each SQL workload to the dbt model it originates from. With Query Tags we can finally accurately split up warehouse costs by the teams that are running dbt on it."
Power BI and Tableau support custom Query Tags at the connection level. Set them once, and every query from that connection carries them automatically. For Tableau, customers have found it useful to use parameters like [WorkbookName] as the tag value, so attribution is preserved even when the workbook is renamed.
For a full list of partner tools that support Query Tags, see the documentation. If your tool is not listed, reach out to your account team.
Custom applications hit your warehouse through APIs and connectors, but the queries they generate carry no application context — no app name, no team name, no customer ID. Query Tags let you attach this metadata at the connection or statement level.
The SQL Statement Execution API supports tagging at the statement level. Tags passed as a parameter apply to that specific execution:
The Python Connector supports both connection-level and statement-level tagging . Set a team name on the connection; override it per-statement when needed:
Matthew Haber, DevOps Engineer, Unit21 shared:
"We moved from one warehouse per team to shared warehouses to cut costs, but lost visibility into which team was driving spend. With Query Tags, we just pass the team name from our Databricks SQL Connector for Python workloads and we have that attribution back – no need to split warehouses again"
For the full list of connector and driver support (Node.js, Go, JDBC, etc), please check the documentation.
Analysts run hundreds of queries a week (exploration, production, debugging, etc) and without labels, they all look the same in system tables. Query Tags let practitioners tag as they go with one line of SQL, anywhere they submit queries: SQL Editor, Notebooks, Dashboards, and Alerts.
Once set, all subsequent statements in the session automatically carry those tags. No need to annotate every query individually. For example, adding the SET QUERY_TAGS statement to each dataset query in an AI/BI dashboard tags every query from that dashboard with ‘environment: production’.
Data practitioners can use this to:
Once queries are tagged, the tags are recorded in the query_tags column of the Query History System Table. Now the hard questions become simple SQL.
Which team is driving warehouse costs?
Many organizations need to allocate shared warehouse costs by team or product. With Query Tags, this is a single query — no warehouse splitting or guesswork.
Which dbt model introduced a regression?
When a pipeline slows down, you need to know which model, not just which warehouse. Filter system.query.history by the auto-injected dbt model name tag to isolate the problem.
Or, skip writing SQL entirely, by asking Genie. Because Query Tags store business context in System Tables, Genie can reason over your workload data in natural language. For example: "Which dbt model had the most number of queries? Which had the longest average query times?”
Query Tags unlock many more monitoring use cases:
Query Tags are in Public Preview today for SQL Warehouses, and we're already working on making it even more helpful for our customers’ monitoring experiences. Please refer to the documentation for updates.
Every untagged query is a missed opportunity for attribution. Whether you need to split warehouse costs by team, trace a slow query back to a specific dashboard, or label analyst work by project — Query Tags give you the context to do it.
If you use dbt, you're already tagging (check your Query History System Table). For Power BI, Tableau, and custom applications, setup takes minutes. For ad-hoc work, it takes one line of SQL.
Query Tags are available today in Public Preview across all clouds. Get started with the documentation.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。