Based on metadata
Learn more about metadata-based dataset monitors.
These monitors are derived directly from the data platform’s system metadata, without scanning row-level values. They surface structural signals, such as:
Last modification time: when the dataset was last updated
Schema changes: any alterations to the schema
Total row count: the overall number of records in the dataset
Total row count change: the delta in row count compared to the previous observation
Because they read only metadata, these monitors are extremely lightweight to compute and ideal for continuous, real-time dashboarding of dataset activity.
Learn more about which features are supported in each metadata data source, such as historical backfilling or partition row count.
Metric Monitoring on table views
Depending on your data source(s), metadata-based Metric Monitors may only be supported on Tables, and not on other data objects e.g. Views.
Alternatives could be to setup these metadata-based Metric Monitors on the source Tables of your non-Table data objects, and/or store these data objects as Tables instead.
Metric Monitoring on table views is currently available on:
BigQuery
Databricks
Postgres
Redshift
Snowflake
Metric Monitors on table views do not use metadata; metadata is not provided for views.
All monitors are supported except Last modification time.
Last modification time must be turned off manually; Soda will attempt to enable it automatically as there is no structural difference between tables and table views.
Unavailable metadata
When Soda Cloud cannot obtain the underlying metadata required to calculate a dataset-level metric, it prevents you from configuring or viewing a metric that would always fail. There are two cases:
Non-retrievable metadata from data source
If a connected data source cannot provide the required metadata for a given dataset-level metric, such as row counts or schema timestamps, Soda will automatically disable that metric both on the Metric Monitors dashboard and in the Configure Dataset Monitors panel so you only see and configure metrics that your source can actually collect.
Unavailable metadata (history)
Some warehouses expose current metadata but don’t provide historical snapshots (for example, systems that only track the latest row count). In this case, Soda will compute the metric starting from your very first scan, but it cannot backfill any history prior to that point. As a result, anomaly detection baselines for that metric begin only at scan #1 and there is no retroactive historical data to train against.
The Schema changes monitor will not add historical metadata and backfilling will not be available, unlike with other metrics. The monitor only starts recording from the moment the dataset is onboarded.
Supported data sources
Athena
✅
✅
—
✅
Azure Synapse
✅
✅
—
✅
BigQuery
✅
✅
✅
✅
Databricks
✅
✅
✅
✅
Dremio
✅
Upcoming
—
✅
MS Fabric
✅
✅
—
✅
MS SQL server
✅
✅
—
✅
MySQL
Upcoming
—
—
✅
Oracle
✅
✅
—
✅
PostgreSQL
✅
✅
—
✅
Redshift
✅
✅
✅
✅
Snowflake
✅
✅
—
✅
Trino
Upcoming
—
—
✅
You are not logged in to Soda and are viewing the default public documentation. Learn more about Documentation access & licensing.
Last updated
Was this helpful?