Query activity

Coalesce Quality reads your warehouse’s query history and uses it to show how your data is used: who queries it, through which tool, what builds each table and what reads it. You can find it in three places: under Catalog → Query activity, on the Access tab of each asset, and as a popularity score on the asset Overview. Everything covers the last 30 days. Queries Coalesce Quality runs itself, for monitors, SQL tests and metadata, are always left out, so our own checks never make a table look used.

​

Which tool ran a query

Most tools label the queries they send to your warehouse. Coalesce Quality reads those labels and attributes each query to the tool that ran it. Looker queries show up as Looker and dbt runs as dbt, even when several tools share one login. Labels are read from where tools usually put them: a comment at the start or end of the SQL, the Snowflake query tag, BigQuery job labels, the Redshift query label and the ClickHouse log comment. The recognised tools include dbt, Coalesce Transform, Fivetran, Looker, Tableau, Sigma, Hex, Metabase, Omni, Power BI, Streamlit, Airflow, Census, Hightouch and Terraform. When a dbt query carries dbt’s standard query comment, it is also linked to the model that ran it. If your dbt project sets its own query-comment, keep the "app": "dbt" JSON in it, or Coalesce Quality can’t tell those queries came from dbt. A query with no label is shown as Untagged. It still counts towards everything on this page, it just isn’t tied to a tool.

​

Service accounts

Not every login is a person. Pipelines, BI tools and applications usually connect with a shared login, and their queries say little about how people use your data. A service account groups those logins under one name and gives them a purpose, such as Loader, Transformer, BI or Application. You manage them in Settings → Service accounts. A service account can match logins by exact name, by a pattern such as FIVETRAN_*, or by narrower conditions like the tool that labelled the queries or the warehouse the login belongs to. Matching by tool means a single login can be split: its Looker queries can belong to a Looker account while the rest stay with the person who owns the login. You can also link a login to a member of your workspace, so their queries show under their name. Some service accounts are built in and need no setup. They cover the logins Coalesce Quality connects with, platform service users (Snowflake service users, Google Cloud service accounts, Databricks and Entra service principals) and well-known tools such as Fivetran, Airbyte, Stitch, Census, Hightouch and Terraform. These tools are recognised by their query labels or by the columns they add to the tables they load. For the logins nothing classifies yet, Coalesce Quality suggests service accounts based on what the logins do. It looks at the tool labels on their queries, names that follow a tool’s setup guide, and behaviour like writing on a fixed schedule or reading at every hour of the day. An AI model looks at the remaining active logins and proposes accounts too. Developers and Admins review all of these on the To review tab of Query activity. In a workspace that has no service accounts of its own yet, the most certain suggestions are applied straight away, named “(Coalesce Quality default)”, and you can edit them like any other account.

​

Leaving pipeline activity out

Popularity should reflect how much people and tools use a table, so pipelines that load, build or test it don’t count as readers. Only reads by people, BI tools, reverse ETL and applications are counted. A query that reads some tables to write another one, like a dbt model build, records those tables as inputs to the build rather than as reads. The purpose of a service account decides whether its other reads count. Loaders, orchestrators, transformers, observability, catalog and CI tools don’t count by default, while BI, reverse ETL and applications do. You can change this for each account. A login that isn’t in any service account is treated as a person, so its reads count. A dbt login left unclassified can make tables look more read than they are, because its tests and other plain queries count as reads. Adding it to a service account with the Transformer purpose fixes that.

​

How each table is built and used

The Access tab of an asset shows what happens to it: what loads, orchestrates, transforms or writes it, what reads it, and how that changed over time. A dbt model and the table it builds are treated as one asset, so both pages show the same activity and nothing is counted twice. The Unused tables tab of Query activity lists tables a pipeline keeps rebuilding that nothing reads, most expensive first, and tables nobody touched at all. On an asset, signals also flag writes from logins outside the pipeline that builds the table, and reads through a shared login that hides who was looking.

​

Popularity

Popularity shows how much an asset is read compared with the other assets on the same platform in your workspace. The asset Overview shows it as up to five stars, with the number of read queries in the last 30 days, or views for BI assets. Hover over it to see how many logins read the asset, when it was last read and how it ranks, for example “More read than 82% of Snowflake assets in this workspace”. The stars use the same scale as Coalesce Catalog. Popularity only counts the reads described in Leaving pipeline activity out, and ranks are recomputed every day. The Popularity section is hidden on assets that have nothing to show yet.

​

From the API or an AI assistant

The same data is available outside the app. The public API has ActivityService for popularity, usage and activity, and ServiceAccountsService for managing service accounts. With the Coalesce Quality MCP server, an AI assistant can ask how a table is used or what a login does, through the usage and popularity tools, and review or apply service accounts through the service account tools.