Snowflake Data Quality Checks: DMFs, dbt Tests, and What Each One Misses

Snowflake data quality checks come in three layers. Native data metric functions (DMFs) let you attach freshness, null, duplicate, and row-count metrics to a table and have Snowflake compute them on a schedule; they require Enterprise Edition and bill serverless compute under a Data Quality Monitoring line. dbt tests cover the invariants you can state as SQL inside your models. A monitoring layer with column-level lineage covers the several hundred tables nobody will ever write a check for, and tells you which dashboards break when one fails. Most teams need all three, in that order of effort.

This is the practical version: what Snowflake gives you for free, exactly where it stops, and what to add. Every limit below comes from Snowflake's own documentation, not from a vendor comparison chart.

What are data metric functions in Snowflake?

A data metric function is a schedulable measurement attached to a table, view, or column. Snowflake ships a set of system DMFs covering the standard quality dimensions: freshness and the related data metric for how long ago a row arrived, null count and null percentage, duplicate count, unique count, row count, blank count, and accepted-values checks. You can also write your own DMF in SQL when the built-in set does not cover your rule.

The workflow is short. You set a data metric schedule on the table, associate one or more DMFs with the table or a specific column, and Snowflake runs them on that cadence, writing results to an event table you can query, alert on, or chart. The default schedule is once every hour, and you can change it to a different interval or trigger it when the table changes.

Two billing details matter more than people expect. You are not billed for creating a DMF, and you are not billed for calling one ad hoc in a SELECT statement. Billing starts when a scheduled DMF computes on an object, and those credits land under a Data Quality Monitoring category on your bill, separate from your warehouses because the work runs on serverless compute. That means a quality program in Snowflake is a metered line item that grows with how many tables you watch and how often, which is a very different cost shape from a per-seat license.

What are the limitations of Snowflake data metric functions?

Snowflake documents the boundaries clearly, and they decide whether DMFs can be your whole quality layer:

That last row is the one that bites. DMFs are excellent at answering "is this table's null rate normal today". They cannot answer "if this column starts arriving null, what does the finance team see tomorrow morning", because Snowflake has no view of what sits downstream of itself.

How do you run data quality checks in Snowflake, step by step?

A workable rollout, in the order that wastes the least time:

1. Pick the tables that matter first. Not every table deserves a metric. Start with the ones feeding executive dashboards, revenue reporting, and anything a customer sees. If you cannot name them, that is itself the finding, and it is what column-level lineage exists to answer.
2. Attach freshness and row count everywhere on that list. These two catch the overwhelming majority of real incidents, which are not subtle statistical drifts but a load that silently did not run. They are also the cheapest metrics to compute.
3. Add null and duplicate checks on join keys and money columns. A duplicated order ID or a null customer key produces wrong numbers rather than obviously broken ones, which is worse. These are the columns worth a targeted metric.
4. Set the schedule honestly. Hourly is the default, but a table that loads once a day does not need an hourly metric and you will pay for the difference. Match the cadence to the load pattern.
5. Route the results somewhere people read. Query the event table, or wire results into a Snowflake alert. A metric nobody sees is an expensive no-op.
6. Write dbt tests for the rules you can state exactly. Anything of the form "this must always be true" belongs in your dbt project next to the model, not in a separate system.

Are dbt tests enough for Snowflake data quality?

No, and the reason is structural rather than a criticism of dbt. A dbt test protects the columns somebody named in a YAML file inside your dbt project. That covers your modeled layer well and costs nothing. It leaves three gaps open.

The first is everything upstream of dbt. Raw landing tables, Snowpipe ingests, and third-party feeds arrive before dbt runs and are usually untested. This is where a surprising share of bad data enters, especially from external sources like partner exports or web-scraped feeds, where a vendor quietly changes a page layout and the pipeline that turns those pages into structured records starts emitting nulls that look perfectly valid to a schema check.

The second is everything downstream. dbt does not know what your BI tool does with a model. A test passing in dbt tells you nothing about whether a Looker explore or a Tableau workbook still resolves.

The third is coverage decay. Test suites go stale. A model gets three new columns in a refactor, nobody adds tests, and the suite stays green while covering a shrinking fraction of the surface. Nothing in dbt flags that the ratio moved.

DMFs, dbt tests, or a monitoring platform: which do you need?

The honest read is that these are complements, not competitors. DMFs are the cheapest way to get real measurements on your most important Snowflake tables without buying anything. dbt tests are the right home for business invariants. A monitoring layer earns its place when the estate is bigger than the set of things anyone will manually instrument, and when alerts need to carry enough context that an on-call engineer can triage them at 7am instead of investigating each one from scratch.

Why data quality checks need lineage to be actionable

Here is the failure pattern almost every Snowflake team hits at the same point in their growth. Quality checks get set up, they work, they start firing, and within two months the channel is muted. Not because the alerts were wrong, but because every alert cost the same twenty minutes of investigation regardless of whether it mattered.

A null-rate alert on stg_payments.processor_ref is either nothing or a serious problem, and the difference is entirely about what reads that column. With downstream impact analysis, the alert arrives already carrying the answer: the four models, two exposures, and one revenue dashboard that depend on that field, named. Triage takes seconds and the priority is obvious.

The same graph works in the other direction, which is arguably more valuable. Before you merge the pull request that renames a column, you can see the full blast radius rather than finding out from a Slack message two days later. That is the part no amount of DMF scheduling gives you, because it requires knowing what exists outside Snowflake.

How much do Snowflake data quality checks cost?

There is no license fee for DMFs beyond needing Enterprise Edition, but the compute is metered. Snowflake bills the serverless compute that runs scheduled DMFs under a Data Quality Monitoring category, tracked in the DATA_QUALITY_MONITORING_USAGE_HISTORY view and rolled into METERING_DAILY_HISTORY. Creating a DMF costs nothing and calling one ad hoc in a SELECT costs nothing; only scheduled computation bills.

Practically, the drivers are how many objects have metrics attached, how many metrics each one has, how often they run, and how much data each metric has to scan. A row count on a small dimension table is trivial. A duplicate-count metric running hourly on a multi-billion-row fact table is not. Check the usage view after the first week rather than guessing, and turn down the cadence on anything that loads daily.

The setup most Snowflake teams end up with

After a couple of iterations, the arrangement that tends to stick looks like this. dbt tests carry the business invariants, close to the models, in version control. Snowflake DMFs run scheduled metrics on the fifty or so tables that genuinely matter, giving measurements inside the platform with no extra vendor. And a lineage-aware monitoring layer sits across the whole warehouse, covering the tables nobody instrumented, watching freshness and schema changes automatically, and attaching downstream impact to every alert so the on-call rotation can tell noise from a real incident.

If you want to see how the wider category lines up, including which vendors publish prices, we keep an honest guide to data quality tools. For how the graph itself gets built from Snowflake query history, see Snowflake data lineage, and for the broader question of detection versus prevention, automated data quality monitoring covers the three layers in more detail.