Data Quality Monitoring Pricing on BigQuery, Snowflake, Databricks and dbt: What the Native Meters Actually Charge

The short answer: native data quality monitoring is rarely free, and on four of the five major platforms the meter runs faster the more often you check. Google bills data quality scans on a premium tier at 0.089 dollars per DCU-hour with no free allowance. dbt meters successful models built. Snowflake requires Enterprise Edition before a data metric function will run at all. Databricks bills its quality monitoring on serverless compute. Only the AWS Glue Data Catalog prices on objects rather than runs.

That single structural detail, that detection speed and cost sit on the same dial, is the thing most build-versus-buy spreadsheets get wrong. This guide lays out what each platform actually meters, quoting the vendor documentation, so you can put a defensible number next to the native column before you compare it with anything else.

The native meters side by side

Verified against vendor pricing and documentation pages in August 2026. Where a vendor does not publish a rate, the row says so rather than guessing.

BigQuery: the free tier does not cover data quality

This is the detail that catches teams out, and it is stated plainly on Google's pricing page. There is a 100 DCU-hour monthly free allowance for Dataplex processing, but it is available for the standard processing SKU only and is explicitly not available for the premium processing SKU. Data quality scans, data profiling and automatic lineage parsing all sit in premium. So the allowance that makes the product look free to pilot applies to the cataloging tier, not the checking tier.

DCU consumption for a quality scan depends on six things: the number of rows, the number of columns, the amount of data scanned, the rule configuration, the table partitioning and clustering, and the frequency of the scan. Five of those describe your data. The sixth is a dropdown. Moving a scan from daily to hourly changes the monthly charge by roughly a factor of twenty four without changing a single rule.

One more billing quirk worth knowing before you forecast: for data quality anomaly detection scans, DCU charges do not apply at all. Those bill on standard BigQuery compute and storage plus BQML model training, processing and deployment, which is a completely separate meter with a different consumption pattern. We broke the whole model down, including committed use discounts, on our page covering Dataplex data quality scan pricing and limits.

dbt: the meter rewards running your tests less often

dbt prices on successful models built. The Developer tier is free for one seat with 3,000 successful models built a month, and Starter is 100 dollars per user per month. Because the unit is a model build rather than a seat-hour, a team that moves from nightly to hourly runs to catch problems sooner multiplies its consumption without adding a single test.

There is a second dbt behavior that costs nothing and catches people anyway. Source freshness takes warn_after and error_after, and the documentation is explicit: if neither is provided, dbt will not calculate freshness. The check does not fail loudly, it simply stops existing. It is also worth knowing that dbt build does not run source freshness, so a pipeline that looks like it covers freshness may not be checking it at all. Our page on dbt source freshness configuration covers the exact syntax and the failure modes.

Snowflake: the edition requirement is the real price

Snowflake data metric functions are genuinely capable. The built-in FRESHNESS function returns elapsed seconds since the most recent update, which is exactly the primitive you want. The cost conversation starts earlier than the compute line, though, because DMFs require Enterprise Edition. For an account on Standard, the price of native freshness monitoring is an edition upgrade across the whole account, not a per-check charge.

After that, several documented behaviors shape what you can actually run. There is a default schedule of one hour on every table and view, a ceiling of 50,000 DMF associations per account, no support on hybrid tables or streams, and a column argument is required for a view or an external table. Reclustering does not trigger a DMF, which matters if you were relying on write activity to drive evaluations.

The constraint that ends most native-only plans on Snowflake is not cost at all. Snowflake documents that you can send email notifications only to Snowflake users within the same account, and every recipient has to be verified. That rules out a PagerDuty inbound address and a shared on-call alias in one sentence.

Databricks: serverless compute, and two gaps in what it watches

What used to be called Lakehouse Monitoring is now Data Quality Monitoring under Unity Catalog, covering anomaly detection and data profiling. It runs serverless, billed under the DATA_QUALITY_MONITORING budget policy, so the charge behaves like compute rather than a license.

Two documented boundaries matter more than the rate. Anomaly detection covers freshness and completeness at the schema level, requires MANAGE permission, handles up to 50 schemas at once, and does not support views or foreign tables. And its completeness check ignores nulls, zeros and NaN, which is a narrower definition of complete than most teams assume when they read the feature name. On the profiling side, the time series and inference profile types cover the last 30 days only, and snapshot profiling tops out at 4TB.

There is also a freshness trap specific to Delta. OPTIMIZE and VACUUM write new table versions without writing any data, so a naive commit-time freshness read reports a table as fresh when nothing new has landed. Our page on Databricks data quality monitoring goes through the workarounds.

AWS Glue: the one meter that does not scale with frequency

Glue Data Quality is built on DeeQu and expressed in DQDL, with more than 25 rule types. The Data Catalog underneath it is free to one million metadata objects and one million requests a month, then one dollar per 100,000 objects, and crawlers bill at 0.44 dollars per DPU-hour. Catalog storage is the rare native quality-adjacent meter that does not punish you for checking often, because it prices what you store rather than how many times you look.

The operational limits are the ones to plan around: 2,000 rules per ruleset, 100,000 statistics per account retained up to two years, and a minimum of three data points before anomaly detection has anything to say. Two asymmetries surprise people. Rule recommendations work in the Catalog but not in ETL, while identifying which specific records failed works in ETL but not in the Catalog. The quality score is the percentage of rules that pass, and detected anomalies do not affect it.

How much does native data quality monitoring cost in total?

There is no single figure, because four of the five platforms meter compute rather than seats. The honest way to size it is to run one scan on your widest table, read the actual consumption off the billing export, then multiply by your table count and intended schedule. On BigQuery that is DCU-hours at 0.089 dollars; elsewhere the charges land in your cloud bill rather than on a software invoice, which is why teams running this at scale usually track it alongside the rest of their cloud and SaaS spend in one read-only view rather than discovering it at quarter end.

Is native data quality monitoring cheaper than a platform?

At small scale, usually yes. A dozen critical tables checked daily with rules somebody already wrote is hard to beat on price. The crossover arrives on three axes: table count, check frequency, and the number of platforms in your estate. Because native meters are per-run and per-platform, cost grows with all three at once, while a flat tier does not move.

The second half of the comparison is not financial. Native checks cover what somebody configured, so the table nobody got around to is unmonitored, and that is reliably the table that breaks. If you want the vendor-side numbers to compare against, our data observability pricing breakdown collects what each commercial platform actually publishes.

Which native tool should I start with?

Start with whichever platform holds your most business-critical tables, and start with freshness and volume rather than value-level rules. Those two catch the majority of real incidents, they need almost no domain knowledge to configure, and they are cheap to evaluate on any of these meters. Add validity and uniqueness rules later, on the specific columns where being wrong costs money.

Then test the alert path before you scale the rules. This is where native tooling most often fails on its own terms: Google caps email at five addresses, Snowflake restricts recipients to users inside the same account, and neither routes to an on-call rotation without engineering work you own. Detection is broadly solved on every platform here. Getting the right human to read it at 3am is the part worth paying for.