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 are data quality monitoring built into the warehouse. A DMF measures one thing about a column or a table: 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. A notification integration mails you or posts to Slack when it breaks. There are 40 system DMFs in SNOWFLAKE.CORE, and you can write your own in SQL. If your data is in Snowflake and you are on Enterprise Edition, turn this on. It is the cheapest data quality you will ever configure.
We do a different job, and we are honest about the line between them. DataShield profiles, classifies and governs the datasets that agents read. Every dataset gets a 20-section analysis profile and a weighted trust score that rolls up by domain and across the estate. Every sensitive column gets a class from a 129-class taxonomy with a reproducible verdict. Datasets are tokenized at ingest; agents query tokenized data over MCP; detokenization is a privileged, audited operation. And every governed tool call is sealed into a hash chain you can verify without trusting us. We do not run monitors on your warehouse tables, and we will not pretend we do. Most Snowflake shops should run both. Also worth reading: our Horizon comparison, since DMFs live inside Horizon.
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, and 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 and stamp the verdict with a config digest, so the same input gives the same answer next quarter. 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. Tokens at ingest, a scope ceiling on every call, and break-glass that auto-revokes are a different control set from a quality check. How Auth does it.
Pick Snowflake DMFs when
- Your data lives in Snowflake and the question is "did this table break overnight". DMFs answer that with no connector, no agent, and no new vendor.
- You want quality checks in SQL, in version control, next to the models that produce the data.
ADD DATA METRIC FUNCTION ... EXPECTATIONis 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 rather than thresholds you guess at. Their anomaly detection does that in preview today.
Bottom line: DMFs watch your Snowflake tables and tell you when a number moves. We profile and classify the datasets agents read, wherever they live, and 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, but we do not schedule checks against your warehouse tables and we raise no alerts. | 40 system DMFs in six groups: accuracy, freshness, schema, statistics, uniqueness, volume. Custom DMFs in SQL that return a number and 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 (diff engine, change classifier, schema evolution, a CDC log), and MDM match configs carry Population Stability Index drift monitoring. Nobody gets paged. | Email and webhook notifications on a violated expectation, switched on per database. Anomaly detection is in preview and learns a predicted range from history, but only for ROW_COUNT and FRESHNESS, and it wants about two weeks of data before it says anything. | ◇ |
| Profiling depth | A 20-section analysis profile per dataset: completeness, field statistics, top values, patterns, column semantics, relationship graph, quality metrics, compliance governance, transformation lineage, business rules, source fingerprint. Plus a weighted composite trust score per entity type, domain and estate, with per-axis breakdown and a trend. | One measurement per DMF, per column, per run. That is the design, and it is a good one for monitoring. It is not a profile, and there is no rolled-up trust score across a domain. | ◆ |
| Sensitive data classification | 129 field classes across PII, PHI, financial data and secrets, with checksum validators and a reproducible verdict stamped with a config digest. Quasi-identifier generalization is available as a switch: dates to year, decade or age band, ZIPs to 3 or 4 digits, partial phones, SSNs and emails, with a measured cardinality-reduction score per column. | 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-preserving, vault-reversible tokens applied at ingest. Detokenization is admin-tier, tenant-scoped, and refused if the audit write fails. Matching runs on real source values, so a tokenized matching field makes an MDM run refuse 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, and names the failure: tampering, insertion, deletion or truncation. Try the verifier. | DMF results land in an event table and status views inside your account. Useful history, and we would query it too. It is a table, so the question "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, a metering guard and a revocation re-check before dispatch. The call fails closed. | Not a DMF concern. Access to results is RBAC on the views. Cortex Data Quality can suggest checks agentically, which is an agent configuring quality, not quality 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, plus ISO 27560 consent receipts. The audit chain still verifies afterwards. | Not a DMF feature. Deleting rows is a warehouse operation, and 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, and quality results are readable as tables through it. There is no dedicated data quality MCP surface that we could find. | ◆ |
| Coverage and deployment | Self-hosted in your own cloud or data center, or a dedicated single-tenant server we operate. Our in-place scan and profile is GA for PostgreSQL only. Snowflake, BigQuery, Databricks and S3 are declared with no handler built yet, so today the Snowflake path is ingest rather than scan-in-place. | SaaS only, and scoped to objects in the account. Tables, views, materialized views, dynamic tables, event tables, external tables and Iceberg tables are supported. 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, 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, which is a knob worth watching. | ◈ |
◆ 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, that it joins to three other datasets, or that the pattern changed last Tuesday. Our 20-section profile says all of that, and 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, and 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 is re-checked against current authority and fails closed. Not at the next token refresh. The next call. That is a different question from whether the table is clean, and 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 and we would not try to copy it. A metric function is a small, testable unit. An expectation is a plain Boolean over the value. You attach both to a table with one SQL statement, set a schedule, and get email or a Slack webhook when it fails. Custom DMFs take more than one table argument, so a referential check across two tables is a normal thing to write rather than a product feature you wait for. Forty system functions cover the checks most teams write first, and the ones nobody bothers to write, like untrimmed strings and invalid JSON. Anomaly detection in preview will learn a range for row count and freshness instead of making you guess a threshold. Cortex Data Quality is aiming at the real blocker, which is that nobody wants to hand-author four hundred expectations. And it all runs where the data already is, so there is no extraction, no connector credential, and no second copy.
Here is the push-back. A DMF answers "is this table behaving". It never answers "what is in this column, who may read it, and what did the agent actually do with it". Those three questions are the ones that turn up in a breach review or an Article 12 request, and they are not monitoring questions at all. There is also a scope problem that gets worse as agents spread. DMFs are bounded by the account, and they do not cover hybrid tables or streams even inside it. The moment your agent joins a Snowflake table to a Postgres extract on someone's laptop, the governed part of your estate is the part you can see, and 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, and 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 and 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, so 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, so the evidence still verifies once the subject is gone. Snowflake gives you deletes, time travel and retention settings, which 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 and no incident workflow. If you want those inside Snowflake, DMFs are the obvious answer and they cost you serverless credits, not a procurement cycle. We sit next to them: 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, with the 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. If you 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, and Snowflake, BigQuery, Databricks and S3 are declared with 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, and serve it over MCP under Auth. Upstream credentials sit in the Connection Vault under one of eight strategies, encrypted at rest and 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, and that is a genuine gap. What we offer instead is a published threat model, a verifier anyone can run, and design-partner terms that include source escrow so 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, and 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 ...), with results 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 and 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, needs about two weeks of history for frequent DMFs (60 days recommended), and has LOW, MEDIUM and HIGH sensitivity. — docs.snowflake.com, 13 Sep 2026
- Notifications for failed checks use email or webhook notification integrations and are enabled at the database level, so every object with a DMF in that database notifies. — docs.snowflake.com, 13 Sep 2026
Other head-to-heads
DataShield vs Lakehouse Monitoring
DataShield vs Lakehouse Monitoring: Databricks watches freshness and drift on Delta tables. We profile and.
Same marketDataShield vs Qualytics
DataShield vs Qualytics: Qualytics scores and monitors the data an AI system reads. DataShield decides.
Same marketDataShield vs Telmai
DataShield vs Telmai: Telmai watches lakehouse data with ML baselines. DataShield profiles and classifies.
AllEvery comparison
One honest scorecard per vendor.
Keep your DMFs. Then see the other half run in your browser: break a live audit chain, revoke an agent mid-session, and read a 20-section profile of a real dataset. Demo Center access is free with a work email.
Get free Demo Center accessYou've seen the proof
Ready for a number? Scope your deployment and we'll price it against your own economics.
Get your quote →