Dataplex Data Quality Scans: Rules, Limits, Pricing

How much do Dataplex data quality scans cost?

Dataplex data quality scans bill on the premium processing tier at 0.089 dollars per DCU-hour in us-central1, with no free allowance. The 100 DCU-hour monthly free tier applies to the standard processing SKU only. Scans bill per second with a one minute minimum, and the charge rises with rows, columns, data scanned, rule configuration, table partitioning, and how often you run the scan.

Last updated August 2026

// COMPARE

Side by side

Dataplex data quality compared

Swipe to see all columns →

Native route on Google Cloud	What it bills on	Published rate (Google Cloud pricing, August 2026)	The ceiling that decides whether it scales
Auto data quality scan	Premium processing, metered in DCU-hours, billed per second with a one minute minimum	0.089 dollars per DCU-hour in us-central1. No free allowance on this SKU	A scan is limited to 1,000 rules, and rules run on BigQuery and Iceberg REST Catalog tables only
Data profiling scan	Premium processing, same DCU meter as quality scans	0.089 dollars per DCU-hour. No free allowance	Profiling tells you what a column looks like today. It does not assert what it should look like tomorrow
Data quality anomaly detection scan	Not DCU at all. Standard BigQuery compute and storage, plus BQML model training, processing and deployment	BigQuery list or capacity pricing plus BQML charges	The bill moves with model training and query volume, so it is forecast separately from every other scan you run
Automatic data lineage parsing	Premium processing, charged on jobs, job executions and lineage links created	Roughly 0.0056 DCU-hours per EntityReference at 0.089 dollars per DCU-hour, plus 2.00 dollars per GiB of lineage metadata storage	Billable whenever the Data Lineage API sourceType is anything other than CUSTOM
Custom lineage reporting	Nothing. Reporting lineage you parsed yourself is free, as are Get, List and Delete calls	No charge	You own the parsing, which is the expensive part
Standard processing (discovery and metadata)	Standard tier DCU meter	0.06 dollars per DCU-hour, and this is the SKU the 100 DCU-hour monthly free tier applies to	Covers cataloging work, not the quality rules most teams are actually shopping for
Dataobservability	A flat monthly tier, not a compute meter	Starter 99 dollars, Team 299, Scale 799 per month, 14-day trial with no card	Monitors Snowflake, BigQuery, Databricks and Redshift read only. Checking more often never changes the invoice

Positioning and pricing models are summarized in good faith from each vendor's public pages, August 2026. Verify current terms with the vendor.

// CAPABILITY

What you get

What continuous monitoring adds once a rule set stops scaling

A bill that does not rise when you check more often

Google documents that the DCU charge for a quality scan depends on the frequency of the scan alongside rows, columns and data volume. That puts detection speed and cost on the same dial: an hourly scan on a wide table costs roughly twenty four times what the daily one costs, so the honest way to run scans cheaply is to run them late. Flat tier pricing removes the tradeoff, because the same monitors run on the same schedule whatever the invoice says.

Coverage that is not a rule authoring project

Every rule in a scan exists because a person wrote it about one column on one table on one day. Metadata driven monitoring derives freshness, volume and schema for every table it can see without anybody writing an assertion, so the tables nobody got around to are covered on day one rather than left silently unchecked.

Alerts that reach an on call rotation

Auto data quality notifications are Cloud Logging entries plus email to a list capped at five addresses, covering score thresholds, job failure and job completion. That is an audit trail. Getting a break into Slack or PagerDuty means building a log sink and a bridge and then owning it. Native Slack and PagerDuty routing ships as configuration instead.

One meter instead of three

Quality scans bill on premium DCU, anomaly detection scans bill on BigQuery compute plus BQML, and lineage bills on parsing volume plus metadata storage. Three meters on one platform means three forecasts and three ways to be surprised. A single monthly tier is a number the finance partner can approve once.

Monitoring that crosses the BigQuery boundary

Rules run on BigQuery and Iceberg REST Catalog tables. A warehouse estate that also holds Snowflake, Databricks or Redshift needs a second answer for everything outside that boundary, and two monitoring systems means two definitions of what a broken table is.

Baselines instead of thresholds somebody guessed

A rule encodes a number a person believed on the day they wrote it. Load volumes drift, seasonality is real, and a static threshold either fires every Monday or never fires at all. Learned baselines per table absorb weekly shape, which is the difference between an alert that gets read and one that gets muted.

// 4 STEPS

How it works

From connected to caught

01

Price the scan you actually intend to run

Take one representative table, run the scan once, and read the DCU-hours off the billing export before you roll the pattern out. Because the charge scales with rows, columns and data scanned, the cost of a scan on your widest fact table is the number that matters, not the cost on a dimension table with nine columns.

02

Decide the schedule on detection latency, then check the bill

Pick the interval from how long you can tolerate bad data downstream, not from what looks cheap. Then multiply. If the honest interval turns out to cost more than a monitoring tier, that comparison is the whole decision and it is better made in week one than in month six.

03

Use sampling deliberately, not as a default

Scans accept a sampling percentage between 0.0 and 100.0 with up to three decimal digits. Sampling cuts DCU consumption directly, and it also cuts the chance of catching a break that affects a small slice of rows. Sample the wide tables you scan hourly, and read the narrow critical ones in full.

04

Keep the rules that encode business logic and stop hand writing the rest

Rule based scans are genuinely good at assertions only your team can express: a status column that must be one of five values, a currency that must never be null on a settled order. Freshness, volume and schema drift are mechanical, identical on every table, and a poor use of a 1,000 rule budget somebody has to maintain.

What you are actually buying when you turn on a Dataplex data quality scan

Google meters this product in Data Compute Units. The pricing page is explicit that a DCU-hour is an abstract billing unit and that the actual metering depends on the individual features you use, which is a polite way of saying you cannot derive the cost of a scan from first principles. There are two processing tiers. Standard processing covers cataloging and discovery work at 0.06 dollars per DCU-hour in us-central1. Premium processing covers three things specifically, and they are the three things most teams come here for: data lineage, data quality, and data profiling. Premium runs at 0.089 dollars per DCU-hour. So the moment you enable a quality scan, a profile, or automatic lineage parsing, you have moved onto the more expensive of the two meters. None of this is hidden, but it is spread across a pricing page and several documentation pages, and the practical consequence only becomes obvious on the second invoice.

The free tier does not cover data quality, and that is the detail worth reading twice

Google Cloud publishes a free usage allowance of 100 DCU-hours a month for Dataplex processing. The qualifier on the pricing page is the important part: the free tier is available for the standard processing SKU only, and is explicitly not available for the premium processing SKU. Data quality scans are premium. So are profiling scans and automatic lineage parsing. The allowance that makes the product look free to try applies to the tier that does the cataloging, not the tier that does the checking. Teams that pilot a quality scan expecting the first 100 DCU-hours to be absorbed find the whole thing billed from the first second. It is worth setting a billing alert on the premium SKU before the pilot rather than after it.

Why scan frequency is the variable that quietly decides your bill

The pricing documentation lists six factors that determine DCU consumption for an auto data quality scan: the number of rows, the number of columns, the amount of data scanned, the data quality rule configuration, the partitioning and clustering settings on the table, and the frequency of the scan. Five of those are properties of your data. The sixth is a choice you make in a dropdown, and it multiplies everything else. Scans support hourly, daily, weekly and monthly schedules, plus custom cron expressions and one time runs. Moving a scan from daily to hourly does not change the rules, the table, or the value of what you learn per run, but it changes the monthly charge by roughly a factor of twenty four. This puts a monitoring product in an odd position. The entire reason to monitor data is to find out quickly, and the meter charges you for finding out quickly. Every team that runs scans at scale eventually arrives at the same compromise, which is to scan the critical tables often, scan everything else nightly, and accept that a break on a table in the second group has most of a day to travel downstream before anybody sees it. Partitioning and clustering do give you real leverage here, because a scan on a well partitioned table reads less data for the same answer. That is worth doing on its own merits. It does not change the shape of the tradeoff.

Anomaly detection scans bill on a completely different meter

This one is easy to miss and it breaks cost forecasts. The pricing page states that for data quality anomaly detection scans, DCU charges do not apply. Instead you pay standard BigQuery pricing for compute and storage, plus BQML charges for model training, processing and deploying. So the same product surface, configured a different way, moves onto an entirely separate meter with its own units and its own consumption pattern. A team that has carefully modeled premium DCU spend and then enables anomaly detection has modeled the wrong thing. There is a second billing wrinkle in the same area: specifying a custom execution identity for a scan changes how the scan is billed. If you are running scans under a custom identity for governance reasons, verify which meter the charges are landing on before you build the forecast around it. For the detection side of this, including what BigQuery offers natively through AI.DETECT_ANOMALIES, the bigquery anomaly detection page goes into the mechanics.

What the documented ceilings cost you in practice

Four limits decide whether scans scale to your estate, and each has a cost consequence rather than just a technical one. A scan is capped at 1,000 rules, which sounds generous until you multiply four or five rules by every table in a mature warehouse and start splitting scans, at which point each additional scan is another scheduled job on the premium meter. Rules run on BigQuery and Iceberg REST Catalog tables only, so anything in Snowflake, Databricks or Redshift needs a second system and a second budget line. Alerting is Cloud Logging plus email to at most five addresses, which means the path to a real incident channel is engineering work you fund and maintain. And column level quality scores are exposed through the API rather than the console, so the granular view you want during triage is a small internal tool somebody builds. None of these are defects. They are the boundary of a governed rules engine, and they are the point at which teams start pricing the alternative.

Committed use discounts and the three year number

If Dataplex is going to be a permanent line item, the committed use discounts are worth modeling early because they are substantial. Premium processing lists at 0.089 dollars per DCU-hour on demand, 0.0801 under the one year BigQuery committed use model, and 0.0712 under the three year model. That is a 10 percent reduction for one year and a 20 percent reduction for three. Standard processing follows the same shape, at 0.06, 0.054 and 0.048. Two cautions when you build the case. The discounts run through BigQuery consumption models with their own IDs and may require opting in, so confirm eligibility with your account team rather than assuming the rate applies. And a three year commitment on a usage meter only saves money if usage stays roughly where you projected it, which for a scan estate that grows with the warehouse is the assumption most likely to be wrong. Model the committed rate against the scan schedule you expect in year three, not the one you are running in month one.

Where lineage billing fits, and the part that is genuinely free

Automatic lineage parsing sits on the same premium meter and is charged on processing complexity: the number of jobs, the number of job executions, and the number of lineage links created. Google publishes a worked example that makes the scale concrete. Reporting lineage to or from one EntityReference costs roughly 0.0056 DCU-hours, so a daily job touching three entities across thirty days comes to about four and a half cents. Lineage metadata storage runs at 2.00 dollars per GiB with a 1 MiB free allowance, and in that same example storage is 1.998 dollars of a 2.07 dollar total. In other words, for ordinary lineage volumes the parsing is close to free and the storage is the line item. The genuinely free part is worth knowing: custom lineage reporting, meaning lineage you parsed yourself and are only storing, carries no charge, and retrieving lineage through Get or List and removing it through Delete are also free. Charges apply when the Data Lineage API sourceType is something other than CUSTOM, such as BIGQUERY, DATAPROC or COMPOSER, because that is Google doing the extraction for you. For how this compares with what commercial lineage vendors quote, the data lineage tools pricing page collects the published rates, and the data quality monitoring pricing comparison lines this DCU model up against the other native meters on Snowflake, Databricks and dbt.

// FAQ

Questions buyers ask

Dataplex data quality FAQ

How much does a Dataplex data quality scan cost?

Quality scans bill on the premium processing tier at 0.089 dollars per DCU-hour in us-central1, billed per second with a one minute minimum. There is no fixed price per scan, because DCU consumption depends on rows, columns, data scanned, rule configuration, table partitioning and clustering, and how frequently the scan runs.

Is there a free tier for Dataplex data quality?

No. Google Cloud publishes a 100 DCU-hour monthly free allowance for Dataplex processing, but the pricing page states it applies to the standard processing SKU only and is not available for premium processing. Data quality scans, data profiling and automatic lineage parsing are all premium, so they bill from the first second of use.

How many rules can a Dataplex data quality scan have?

The number of rules per data quality scan is limited to 1,000. Rules can be row level or aggregate, and each is assigned to one of seven fixed dimensions: freshness, volume, completeness, validity, consistency, accuracy and uniqueness. Large estates split coverage across multiple scans, and each additional scan is a separate scheduled job on the premium meter.

Can Dataplex send data quality alerts to Slack or PagerDuty?

Not directly. Notifications are Cloud Logging entries plus email to up to five addresses, covering scores below target, job failure and job completion. Reaching Slack or PagerDuty means routing the log entries yourself through a sink and a bridge you build and maintain, which is why teams with an on call rotation usually put a monitoring layer in front of it.

Which tables can Dataplex data quality rules run on?

Data quality rules run on BigQuery and Iceberg REST Catalog tables only. Anything held in Snowflake, Databricks or Redshift falls outside the boundary and needs a separate monitoring answer, which is the practical reason multi warehouse teams end up running a platform layer above the native tooling rather than instead of it.

Was Dataplex renamed to Knowledge Catalog?

Yes. Dataplex Universal Catalog was renamed Knowledge Catalog on April 10, 2026, and the API, CLI and IAM names were left unchanged. Billing SKUs and documentation still carry the Dataplex name, which is why a pricing page headed Knowledge Catalog lists Dataplex Universal Catalog standard and premium processing line items.

More of the platform

Data quality tools Data quality monitoring Data quality checks Data lineage Data pipeline monitoring Data anomaly detection Data incident management Data observability pricing Open source data observability Data quality dashboard Data lineage diagram tool Data contracts Data quality management tools Data observability market Data lineage tools Column level lineage BigQuery anomaly detection Snowflake anomaly detection Databricks data quality monitoring Redshift data quality Airflow data quality checks dbt observability Monte Carlo pricing Collibra pricing Acceldata pricing Power BI data quality Data lineage tools pricing Snowflake data metric functions dbt source freshness Tableau data quality Data observability for Snowflake dbt data observability BigQuery data quality Databricks data observability

Dataplex Data Quality Scans: Rules, Limits, and Pricing per DCU-Hour