INFORMATION_SCHEMA freshness
Per-table thresholds via SNOWFLAKE_MONITORED_TABLES.
Integration · Warehouse
Snowflake
Table freshness from INFORMATION_SCHEMA.LAST_ALTERED — metadata only, beside BigQuery.
The problem
Snowflake teams need the same calm freshness SLAs without row reads or a second noisy suite.
The outcome
Connect a programmatic access token. VectorData watches LAST_ALTERED on your marts and joins the same Watchdog queue as BigQuery freshness and dbt failures.
Live
Freshness SLAs
Access
PAT / SQL API
Rows
Never read
What you get
Multi-warehouse sweep
BigQuery + Snowflake in one monitoring run.
Same ethos as BigQuery
Metadata-first; no SELECT * on marts.
Cost / deep lineage next
Freshness Live; warehouse spend depth expands next.
- ✓Docs: /docs/integrations/snowflake
- ✓Solution: /solutions/technologies/snowflake
- ✓Product: /vectordata/freshness
- ✓Security ethos
Related
Integration · Warehouse
Google BigQuery
Freshness and cost from INFORMATION_SCHEMA and JOBS — never result rows.
Integration · Transform
dbt Core
Upload run_results.json or wire a webhook for calm failure triage.
Integration · Transform
dbt Cloud
Same triage path for Cloud runs — artifact-first, rows never exported.
Try VectorData, then decide
Open workspace, or book a Data Stack Health Audit credited toward Managed.