Head-to-head · updated 13 September 2026

DataShield vs Snowflake DMFs: your tables passed the check, but what did the agent read?

Snowflake Data Metric Functions check data in the warehouse. A DMF checks one thing about a column or a table. Think null count, blank count, duplicates, row count, freshness, schema changes. An expectation turns that number into a pass or a fail. A schedule runs it. Hourly, every five minutes, on a cron, or on every DML change. Then a note goes to you: email, or a Slack post, when it breaks. There are 40 system DMFs in SNOWFLAKE.CORE. You can write your own in SQL, too. Is your data in Snowflake, on Enterprise Edition? Turn this on. It is the cheapest data check you will ever set up.

We do a different job. We are honest about that line. DataShield profiles, classifies and governs the datasets that agents read. Every dataset gets a 20-section profile. It also gets a trust score, rolled up by domain and across the estate. Every sensitive column gets a class from a 129-class list, with a repeat-safe verdict. Datasets get tokenized at ingest. Agents query tokenized data over MCP. Detokenization is a privileged, audited step. Every governed tool call gets sealed into a hash chain you can check, with no need to trust us. We do not watch your warehouse tables. We will not claim we do. Most Snowflake shops should run both. Also worth reading: our Horizon comparison, since DMFs live inside Horizon.

Get free Demo Center access Get an instant quote

The short version

Pick DataShield when

The data agents read is not all in Snowflake. Half your sensitive columns sit in Postgres, a file drop, or a vendor export. DMFs cannot see any of it.
You need to know what is in the column. Not just how many nulls it has. We label it against 129 field classes. We stamp the verdict with a config digest. Same input, same answer, next quarter too. How the catalog works.
Someone will ask you to prove an agent's access log was not edited. Our chain answers with math. Run the verifier.
The reader is an agent, not a person. Tokens at ingest. A scope ceiling on every call. Break-glass that auto-revokes. That is a different control set from a quality check. How Auth does it.

Pick Snowflake DMFs when

Your data lives in Snowflake. The question is "did this table break overnight". DMFs answer that. No connector, no agent, no new vendor.
You want quality checks in SQL, in version control, next to the models that produce the data. ADD DATA METRIC FUNCTION ... EXPECTATION is a good, plain design.
You need alerting and on-call flow. Failed expectations fire email or webhook notifications. We have none of that.
You want volume and freshness anomalies learned from history. Not thresholds you guess at. Their anomaly detection does that in preview today.

Bottom line: DMFs watch your Snowflake tables. They tell you when a number moves. We profile and classify the datasets agents read, wherever they live. We keep proof of what the agents did with them. Those are neighbours, not rivals. Buy us because of the agent, not because of the null count.

Feature by feature

Competitor cells describe what Snowflake's public docs say as of the date above. If we have mischaracterised something, email support@myorg.ai and we will correct it, credited.

What matters	DataShield	Snowflake DMFs	Edge
Scheduled quality checks and expectations	None. We profile on ingest and recompute a trust score hourly, across the estate. Warehouse tables do not get scheduled checks. We raise no alerts.	40 system DMFs in six groups: accuracy, freshness, schema, statistics, uniqueness, volume. Custom DMFs in SQL return a number. They can take several table arguments, so referential checks work. Expectations are a real object, with status views. Schedules run on an interval, a cron, or on data change.	◇
Alerting and anomaly detection	None, by design. We detect change and drift in datasets we govern. Tools: a diff engine, a change classifier, schema evolution, a CDC log. MDM match configs carry Population Stability Index drift monitoring too. Nobody gets paged.	Email and webhook notifications fire on a violated expectation, switched on per database. Anomaly detection is in preview. It learns a predicted range from history, but only for ROW_COUNT and FRESHNESS. It wants about two weeks of data before it says anything.	◇
Profiling depth	A 20-section profile per dataset: completeness, field stats, top values, patterns, column semantics, relationship graph, quality metrics, compliance governance, transformation lineage, business rules, source fingerprint. Plus one trust score, per entity type, domain and estate, with the breakdown behind it and a trend line.	One measurement per DMF, per column, per run. That is the design. It is a good one for checks. It is not a profile. There is no rolled-up trust score across a domain.	◆
Sensitive data classification	129 field classes, across PII, PHI, financial data and secrets. Checksum checks back them up. Each verdict repeats the same way twice, stamped with a config digest. Quasi-identifier generalization is a switch you flip. Dates go to year, decade or age band. ZIPs go to 3 or 4 digits. Phones, SSNs and emails get part masked. Each column gets a size-cut score.	Not part of DMFs. Snowflake does classification elsewhere, in Horizon, with a semantic category and a privacy category. A DMF counts nulls. It does not tell you the column holds an SSN.	◆
Data handling and tokenization	Deterministic, join-safe, vault-reversible tokens, set at ingest. Detokenization is admin-tier, tenant-scoped, and blocked if the log write fails. Matching runs on real source values. A tokenized match field makes an MDM run stop, rather than merge badly.	Out of scope. DMFs measure data. They never change it or hide it.	◆
Audit evidence	SHA-256 hash chain, with Ed25519-signed checkpoints that are themselves chained. Verification returns clean, attested damage, or tampered. It names the failure: tampering, insertion, deletion or truncation. Try the verifier.	DMF results land in an event table and status views inside your account. That is useful history. We would query it too. It is a table, though. "Who could have written to it" has a permissions answer, not a cryptographic one.	◆
Agent authorization	Every governed tool call passes a scope ceiling, a consented-tool allowlist, an authority tier, and a metering guard. It gets a revoke re-check before it goes out. The call fails closed.	Not a DMF concern. Access to results is RBAC on the views. Cortex Data Quality can suggest checks on its own. That is an agent setting up checks, not checks governing an agent.	◆
Break-glass	Scoped, time-boxed emergency access for agents, admin and IP-allowlist gated, auto-revoking, and impossible to quietly remove from the log.	Not described in their public material.	◆
GDPR erasure	Crypto-shred of per-subject key material, cited to ISO/IEC 27040 and Article 17. ISO 27560 consent receipts too. The audit chain still verifies afterwards.	Not a DMF feature. Deleting rows is a warehouse operation. A DMF will happily measure the result.	◆
MCP and agents	More than 200 MCP tools across Ontology, Auth, Corpus and Lighthouse. An agent can list datasets, read a profile, check the trust score, and act on it. All under a tool token, with an enforced scope ceiling and RFC 8693 delegation.	Snowflake has a managed MCP server at the platform level. Quality results are readable as tables through it. We could not find a dedicated data quality MCP surface.	◆
Coverage and deployment	Self-hosted, in your own cloud or data center. Or on a single-tenant server we run for you. Our in-place scan and profile is GA for PostgreSQL only. Snowflake, BigQuery, Databricks and S3 are named, but have no handler built yet. So today the Snowflake path is ingest, not scan-in-place.	SaaS only, scoped to objects in the account. Tables, views, materialized views, dynamic tables, event tables, external tables and Iceberg tables are covered. Hybrid tables and streams are not. Enterprise Edition is required.	◈
Maturity signals	Live in production (Guardian and Lighthouse since April 2026). SOC 2 not yet certified, and we say so.	Public company, huge install base. Platform-level SOC 2 Type II, ISO 27001, HIPAA, PCI DSS and FedRAMP. Expectations are GA. Anomaly detection and Cortex Data Quality are preview.	◇
Pricing	Published model, scoped instant quote, no sales wall.	No SKU. Scheduled DMF runs bill as serverless compute under "Data Quality Monitoring" on the invoice. This is tracked in a usage history view. Ad hoc calls are free. Enterprise Edition is the real price of entry. Costs scale with how often you check. Watch that knob.	◈

◆ DataShield leads◇ Snowflake DMFs leads◈ comparable

Snowflake claims are drawn from docs.snowflake.com, last checked 13 September 2026. We link the pages below rather than work from memory.

Three things you get here that you won't get from warehouse-native quality checks

A profile, not a metric

A DMF tells you a column has 412 nulls. It does not tell you the column holds patient identifiers. It does not tell you it joins to three other datasets. It does not tell you the pattern changed last Tuesday. Our 20-section profile says all of that. The trust score rolls it up, so a domain owner sees one number, with the axes behind it. See what the catalog records.

Proof that leaves the account

Quality history lives in the warehouse that also bills your compute. Our evidence is a hash chain with signed checkpoints. The verifier says what broke, not just that something did. It keeps verifying after you export it, after you migrate, and in front of an auditor with no Snowflake login. Try it in your browser, no signup.

Authority that can change mid-flight

An analyst leaves on a Friday. Their agent is 20 minutes into a 40-minute job. The next governed tool call gets re-checked against current authority. It fails closed. Not at the next token refresh. The next call. That is a different question from whether the table is clean. It is the one that shows up in the incident report. How Auth does it.

Where Snowflake DMFs are genuinely stronger

The design is good. We would not try to copy it. A metric function is a small, testable unit. An expectation is a plain yes or no on the value. You attach both to a table with one SQL line. Set a schedule. Get an email or a Slack note when it fails. Custom DMFs take more than one table as input. So a check across two tables is a normal thing to write, not a feature you wait for. Forty built-in functions cover the checks most teams write first. They also cover the ones nobody bothers to write, like loose strings and bad JSON. Anomaly checks in preview will learn a range for row count and freshness, instead of a threshold you guess. Cortex Data Quality aims at the real snag: nobody wants to write four hundred checks by hand.

And it all runs where the data already sits. No pull-out, no connector key, no second copy.

Here is the push-back. A DMF answers "is this table okay". It never answers "what is in this column, who may read it, and what did the agent do with it". Those three questions turn up in a breach review. Or an Article 12 request. They are not check questions at all. There is also a range problem, and it gets worse as agents spread. DMFs stop at the account edge. They skip hybrid tables and streams, even inside it. Your agent joins a Snowflake table to a Postgres file on someone's laptop. At that point, the part you govern is the part you can see. The risky part is the part you cannot. We would rather own that second part than compete for the first.

Questions worth asking both of us

These are the questions we would want answered if we were the ones buying. Ask them on every call, ours included.

Can you cryptographically prove an audit log entry wasn't deleted?

DataShield: yes. Each record commits to the one before it. Checkpoints are Ed25519-signed and chained. The verdict tells deletion apart from truncation and from tampering. Try it on a sample chain at /verify. Snowflake: DMF and expectation results are written to an event table, exposed through status views in your account. That is a durable history, not tamper evidence. Ask who holds write access to the event table, and what would show if a row went missing.

What happens to a revoked agent mid-session?

DataShield re-checks authority on every governed tool call. Revocation lands on the very next call, and the context drops to anonymous. Snowflake evaluates RBAC as the connecting role. Pulling a grant stops new work. But we could not find published mid-session revocation semantics for an in-flight session in their docs. Ask how long a compromised agent keeps working after you pull its access.

How does GDPR erasure interact with the audit trail?

DataShield crypto-shreds per-subject key material and issues an ISO 27560 consent receipt. Actor identities in the chain are HMAC-committed. The evidence still verifies once the subject is gone. Snowflake gives you deletes, time travel and retention settings. That is a different thing from destroying the key that makes a value readable. Ask for the mechanism, not the workflow.

Do you replace Data Metric Functions?

No, and we would think less of a vendor who said yes. We have no scheduled checks on your tables. No expectations, no alerts, no on-call integration. No freshness SLA, no incident workflow. Want those inside Snowflake? DMFs are the obvious answer. They cost you serverless credits, not a procurement cycle. We sit next to them. We profile and classify the datasets your agents read, tokenize the sensitive ones, and keep evidence of every read.

Is your trust score the same idea as an expectation?

Related, but not the same. An expectation is a pass or fail on one measurement of one column. Our quality_status is a weighted composite over the active quality axes, for an entity type, a domain, or the whole estate. It carries a per-axis breakdown, a declared target, and a trend tail. It recomputes hourly. Think of it as a score a data owner reads once a week. Not a check that pages an engineer at 3am. Need the 3am page? That is a DMF.

Do you connect to Snowflake as a source today?

Not as a scan-in-place provider. Our catalog scan and profile is GA for PostgreSQL only. Snowflake, BigQuery, Databricks and S3 are declared, but have no handler built yet. We would rather tell you now than let you find out in week three. What works today: ingest the data you want agents to touch. Tokenize it at ingest. Classify it. Serve it over MCP, under Auth. Upstream credentials sit in the Connection Vault, under one of eight strategies. They are encrypted at rest, never readable back.

Does DataShield have SOC 2?

Not yet, and we will not imply otherwise. Snowflake has SOC 2 Type II, ISO 27001, HIPAA, PCI DSS and FedRAMP at the platform level. That is a genuine gap. What we offer instead: a published threat model, a verifier anyone can run, and design-partner terms that include source escrow. That way a small vendor is not a single point of failure. Details on the security page.

A DMF "measures an attribute of your data" and is a building block of a check. An expectation decides pass or fail. Billing appears as "Data Quality Monitoring", tracked in DATA_QUALITY_MONITORING_USAGE_HISTORY. Only scheduled runs are billed. Limit: 50,000 DMF associations per account. Hybrid tables and streams are not supported. - docs.snowflake.com, 13 Sep 2026
There are 40 system DMFs in the SNOWFLAKE.CORE schema across six categories: accuracy (20), freshness, schema, statistics, uniqueness and volume. - docs.snowflake.com, 13 Sep 2026
Expectations are GA on Enterprise Edition, written as ADD DATA METRIC FUNCTION ... EXPECTATION name (VALUE ...). Results land in DATA_QUALITY_MONITORING_RESULTS_RAW and the DATA_QUALITY_MONITORING_EXPECTATION_STATUS view and table function. - docs.snowflake.com, 13 Sep 2026
Schedules support an interval such as '5 MINUTE', 'USING CRON ... UTC', or TRIGGER_ON_CHANGES, which fires on DML but not on reclustering. Custom DMFs must return a number. They may take several table arguments. - docs.snowflake.com, 13 Sep 2026
Data quality anomaly detection is a preview feature. It supports only ROW_COUNT and FRESHNESS. It needs about two weeks of history for frequent DMFs (60 days recommended). It has LOW, MEDIUM and HIGH sensitivity. - docs.snowflake.com, 13 Sep 2026
Notifications for failed checks use email or webhook notification integrations. They are enabled at the database level. Every object with a DMF in that database notifies. - docs.snowflake.com, 13 Sep 2026

Other head-to-heads

Same market

Get free Demo Center access

You've seen the proof

Ready for a number? Scope your deployment and we'll price it against your own economics.

Get your quote →