Metadata queries
Coalesce Quality reads metadata from each warehouse integration every 30 minutes. One cycle fetches the table metrics and the query logs together, so the warehouse resumes once per cycle. These queries read system views such asINFORMATION_SCHEMA and ACCOUNT_USAGE, not your tables. Table stats monitors use the same metadata, so they add no queries of their own on tables.
On Snowflake, the cost depends on how often the warehouse resumes more than on how many tables you have. Snowflake bills a warehouse for at least 60 seconds each time it resumes. With a dedicated XSMALL warehouse (1 credit per hour) and AUTO_SUSPEND = 60, as in the Snowflake setup script, each cycle bills about 60 to 90 seconds. At 48 cycles a day, that is about 1 credit per day.
Data queries
These checks query the table itself, so they scan data:- Custom monitors, including custom freshness and volume monitors
- Field stats monitors
- SQL tests
- Table stats on views, which a deployment rule queries once per hour
Keeping the cost low
- Use table stats for freshness and volume where you can. They read metadata, not data.
- Run custom monitors and SQL tests daily unless you need them more often.
- Give custom monitors a time partition column, so each run reads only new data.
- If cost matters more than isolation, connect the integration to a warehouse that is already running for other work. The monitoring queries then do not cause resumes of their own.
Finding the queries in your warehouse
The queries Coalesce Quality runs carry a SQL comment with a JSON object that starts with{"app":"synq", for example /* {"app":"synq","integration_id":"...","task":"...","workspace":"..."} */. On Snowflake, the same JSON is also the query tag.
On Snowflake, this query shows the monitoring queries of the last 7 days per day, warehouse and task. The task fetch_monitor_metrics is the monitors that query data, and execute_sql_test is SQL tests:
SYNQ_WH with the name of your warehouse:
ACCOUNT_USAGE views with a delay of up to a few hours.