Head-to-head · updated 13 September 2026
DataShield vs Lakehouse Monitoring: who watches the table, and who proves what the agent did with it?
Databricks calls it Data Quality Monitoring now. The pitch is blunt: "Intelligent quality monitoring for data and AI on the lakehouse". Teams can watch their tables "without added tools or complexity." That's aimed at every data observability vendor, with a Databricks link. And it lands. Anomaly detection flags tables whose freshness or row counts look wrong. Data profiling writes profile and drift metric tables back to Delta. A dashboard and SQL alerts sit on top. If your data is on the lakehouse, you own this now.
We do a different job, on the same tables. Ontology gives a dataset a 20-section profile. It scores a trust KPI you can roll up by domain. It labels each field against 129 PII, PHI, financial, and secret classes. Then Auth governs what an agent may do with that data. Datasets get tokenized at ingest. Agents query tokenized data over MCP. Turning a token back is a special, audited step. We have no freshness monitor, and no alerting. We say so in the table below.
The short version
Pick DataShield when
- The data you worry about isn't all in Databricks. We scan and profile a live PostgreSQL source in place, with no rows leaving it. Snowflake, BigQuery, Databricks, and S3 are on the roadmap, not shipped.
- You need to know which fields are sensitive, not just which table went stale. We label fields against 129 classes, all 18 HIPAA Safe Harbor markers included. The result repeats from a config digest.
- An examiner will ask you to prove a log wasn't edited. Ours is a SHA-256 chain with signed checkpoints. Break it in a browser, and watch the verifier name the fault. Try it.
- Agents read the data, and someone has to answer for that. Each checked tool call re-checks access. You can pull an agent's access mid-session. How Auth works.
Pick Lakehouse Monitoring when
- Your tables are Delta tables in Unity Catalog. Turn it on per schema, or across a whole catalog. Pay only serverless compute. No new contract, no new vendor.
- You want freshness and completeness anomaly detection. Databricks runs a background job that learns what normal looks like, and flags tables that drift off it. We have nothing like this.
- You want drift metric tables, a dashboard, and alerts. Profile and drift metrics land back in Delta. A SQL alert sits on top, and pages you in Slack or PagerDuty. Again, not us.
- Root cause matters more than proof. Monitoring reads the lineage the platform already captured, so the hunt starts closer to the answer.
Bottom line: Lakehouse Monitoring tells you a table looks wrong. DataShield tells you what's in the data, who may touch it, and what happened when an agent did. In a Databricks shop, we expect to run alongside it, not instead of it.
Feature by feature
Competitor cells reflect Databricks' public site and docs, as of the date above. Spot a mistake? Email support@myorg.ai. We'll fix it, and credit you.
| What matters | DataShield | Lakehouse Monitoring | Edge |
|---|---|---|---|
| Anomaly detection and freshness | None, and we won't fudge this. There's no stat-based anomaly check in the stack. No freshness SLA, no on-call alert. If a table stops loading at 3am, we're not the thing that wakes you. Not our job. | A background job checks tables for freshness and completeness. Turn it on per schema, or across a whole catalog. The docs mark it Public Preview. It skips views and foreign tables. Completeness ignores nulls, zeros, and NaN. | ◇ |
| Profiling depth | A 20-section profile per dataset. Completeness, field stats, top values, patterns. Column meaning, tie graph, quality scores. Rule notes, lineage, a source fingerprint. A weighted trust score rolls up by type, domain, and estate. It recomputes hourly. | Profile metric tables with summary stats. Plus drift metric tables against a baseline. Plus custom metrics you set in SQL. Broad, and it covers model outputs too, not just tables, which we don't. | ◈ |
| Alerting, dashboards and incidents | No alert layer, and no issue flow. We surface change and drift through a diff engine, and a change tagger. Plus schema tracking. Plus a CDC log, which you read or query. Nobody gets paged. | A SQL query over the metric table. A Databricks SQL alert on top. Email by default, plus webhooks into Slack or PagerDuty. A ready-made dashboard ships with the monitor. | ◇ |
| Sensitive-data classification | 129 field types cover PII, PHI, financial data, and secrets, with checksum checks (Luhn, NPI, Verhoeff, ABA, IBAN, GTIN), column-name lists, and anti-pattern rules. Results are fixed and stamped with a config digest, so two runs match. No model, so no drift. | Not part of monitoring. Unity Catalog handles tagging and classification on its own. The monitor reports that a column changed. Not that it holds a medical record number. | ◆ |
| Audit evidence | A SHA-256 hash chain, with Ed25519-signed checkpoints. Those checkpoints chain too. Verification returns a named verdict. It tells tampering apart from insertion, deletion, and cut. Ed25519 audit-signing keys stay on your instance, in a key folder you control. Rotation fails closed on an unknown key. KMS or HSM custody is a built seam in Auth. Not a shipped link. Public demo. | Monitoring writes metric tables, not evidence. Platform audit events land in a Unity Catalog system table. We found no claim that those records are hash-chained. Or signed, or checked on their own. | ◆ |
| Agent authorization | Each checked tool call runs a fixed sequence, before dispatch. Auth gate, consented-tool narrowing, token scope ceiling. Declared access tier, revocation check, then metering. Hand-offs use RFC 8693 token exchange, with a set scope ceiling. | Out of scope. The docs are plain: monitoring "does not modify any tables it monitors, nor does it add overhead to any jobs that populate these tables." It's a reader. Access control lives in Unity Catalog. | ◆ |
| Break-glass | Scoped, time-boxed emergency access for agents. Admin plus IP allowlist plus step-up, auto-revoking. It can't be quietly wiped from the log. | Not a monitoring feature, and not covered in the docs we read. Ask them. | ◆ |
| GDPR erasure | Crypto-shred of the subject's key material. Plus ISO 27560 consent receipts. Actor IDs in the chain are HMAC-committed. The proof still checks out after the subject is gone. | Delete the rows. Metric tables hold stats rather than raw values, which helps. But what erasure does to old profiles and drift baselines isn't spelled out. | ◆ |
| Tokenization and data handling | Datasets get tokenized at ingest. Agents query tokenized data over MCP. Turning a token back is a special, audited step. Tokens are fixed, join-safe, and vault-reversible. Each lookup is logged, or refused. Masking and generalization are switches you flip, not defaults. | No token vault, and no reversible masking in the monitoring path. Monitoring reads the table as it is, and writes stats beside it. | ◆ |
| MCP and agents | More than 200 MCP tools, across Ontology, Auth, Corpus, and Lighthouse. An agent can ask for a dataset profile, and read the trust score. It can act on it too. All under a tool token with a scope ceiling. | The tagline pairs quality with AI. Databricks has managed MCP servers elsewhere in the platform. We found no MCP surface for the monitor itself. An agent reads the metric tables with SQL, like anyone else. | ◆ |
| Reach and deployment | Self-hosted, in your own cloud or data center. Or on a dedicated single-tenant server we run for you. Docker images for Auth, Ontology, Corpus, and Lighthouse. A signed deploy file, Guardian checks it. Profiling in place covers PostgreSQL today, not your whole estate. | Unity Catalog tables on a Databricks workspace, on AWS, Azure, or GCP. Serverless compute needed for anomaly detection. Data outside the lakehouse is outside the monitor. | ◆ |
| Maturity and pricing | Live in production. Guardian and Lighthouse have run since April 2026. SOC 2 isn't certified yet, and we say so. Published pricing, and an instant quote, no call needed. | A very large company with a deep enterprise bench. No license to buy. It bills as serverless DBUs, under the DATA_QUALITY_MONITORING product. Split out from serverless jobs in February 2026. Cheap to start, hard to forecast before you turn it on. | ◇ |
◆ DataShield leads◇ Lakehouse Monitoring leads◈ comparable
Databricks claims are drawn from databricks.com and docs.databricks.com. Last checked 13 September 2026. We link them below, not just a memory of them.
Three things you get here that you won't get from a built-in table monitor
A profile that names the risk, not just the shape
A metric table tells you a column's null rate moved. It doesn't tell you the column is a medical record number. We label fields against 129 classes. All 18 HIPAA Safe Harbor markers are included, plus eight non-US ID formats. A checksum check backs each label. The catalog stores no column values by default. What Ontology does.
A witness that isn't the defendant
Databricks runs the job. It writes the metrics, and holds the keys to the storage. That's fine for quality work. It's thin when an examiner asks for the March logs. They want to know nobody edited them. Our chain sits in a separate control plane, with its own signing keys. Edit a record in your browser, and the verifier names the exact fault. Try it, no signup.
Access that can change mid-flight
An analyst quits on a Friday afternoon. Their agent is forty minutes into a job over your client table. With DataShield, the next checked tool call re-checks access, and fails closed. A quality monitor would just report that the job ran. How we deploy and secure it.
Where Lakehouse Monitoring is genuinely stronger
Three things, and none of them are close. First, anomaly detection. Databricks learns the normal rhythm of a table. It tells you when freshness or row count slips. On a schema or across a catalog, with one click. We don't have that at all, and building it isn't a weekend job. Second, the day-to-day loop. Metric tables, a dashboard, a SQL alert, a page to your phone. Data teams live in that loop. A profile you have to go read isn't the same product. Third, distribution. It's in the account now. Nobody has to win a procurement cycle to try it. That's why standalone quality vendors keep adding features. It keeps them ahead of a free default.
Here's the push-back, and it's narrow. Anomaly detection is marked Public Preview. It skips views and foreign tables. The docs say completeness ignores nulls, zeros, and NaN. So a table can arrive on time, at full row count. Stuffed with zeros. And pass. More to the point, the monitor is a reader by design. Its own docs say it doesn't touch the tables it watches. It doesn't add overhead to the jobs that fill them, either. That's the right call for a monitor. It means quality is the only question it answers. Who may read the column? What was tokenized before the model saw it? Can the log of that read be checked later? None of that is in scope. In a 2026 agent estate, those are the questions asked in the room. The room with the lawyers.
Our fuller argument about lakehouse governance is on the Unity Catalog page.
Questions worth asking both of us
These are the questions we'd want answered if we were buying. Ask them on each vendor call, ours too.
Can you cryptographically prove an audit log entry wasn't deleted?
DataShield: yes, it can. Each record locks to the one before it. Checkpoints are signed and chained. Verification tells deletion apart from truncation and tampering. Try it at /verify. Lakehouse Monitoring: it's not an audit product. Databricks logs platform activity in a Unity Catalog system table. We found no claim that those rows are hash-chained or signed. Ask for the integrity proof, not the query.
What happens to a revoked agent mid-session?
DataShield re-checks access on each checked tool call. A pull bites on the very next call. A quality monitor has no answer here, and shouldn't pretend to. Access is Unity Catalog's job. Ask Databricks how long a compromised agent keeps reading. After you pull its grants. Then ask what record of that reading you can hand to an auditor.
How does GDPR erasure interact with the audit trail?
DataShield crypto-shreds the subject's key material, and issues an ISO 27560 consent receipt. Actor IDs in the chain are HMAC-committed. The chain still checks out after the subject is erased. On the Databricks side, deleting rows is easy. What we couldn't find: what erasure does to profile history. Or to drift baselines already written to metric tables. Ask both of us.
Is DataShield a Lakehouse Monitoring alternative?
Only if what you wanted was profiling, plus sorting, plus proof. Wanted freshness alerts on Delta tables? No. We have no anomaly detection, no freshness SLA. No monitors on warehouse tables, no issue management. Any vendor who tells you those match a profile is selling. Most Databricks shops that talk to us keep the monitor. They add a layer for sorting, and agent proof.
What does data quality monitoring actually cost on Databricks?
It bills as serverless DBUs, under the DATA_QUALITY_MONITORING product. Databricks split that out from serverless jobs in February 2026. So the answer depends on your table count and refresh rate. You can only see it after you turn it on. Ask for an estimate at your scale. Ask what happens to the bill. When someone turns it on across a whole catalog. Our pricing is published, and the quote is instant.
Does DataShield have SOC 2?
Not yet, and we won't say otherwise. Auth runs live in production. It ships with a public threat model, and a verifier anyone can run. Guardian and Lighthouse have run since April 2026. Design-partner terms include source escrow. One small vendor isn't a single point of failure, that way. Details on the security page.
- Product page: "Intelligent quality monitoring for data and AI on the lakehouse." Their pitch. Also: "monitor the health of their datasets without added tools or complexity." Their words. - databricks.com, 13 Sep 2026
- Anomaly detection: "Databricks creates a background job that monitors tables for freshness and completeness." Marked Public Preview. Also, it "does not support views or foreign tables." And completeness "does not take into account metrics such as the fraction of nulls, zero values, or NaN." Their words. - docs.databricks.com, 13 Sep 2026
- Scope statement: "Data quality monitoring does not modify any tables it monitors, nor does it add overhead to any jobs that populate these tables." Their claim, verbatim. - docs.databricks.com, 13 Sep 2026
- Alerting is assembled, not built in. "You create a Databricks SQL query on the profile metrics table or drift metrics table. You then create a Databricks SQL alert for this query." Email by default. Webhooks to Slack or PagerDuty, too. - docs.databricks.com, 13 Sep 2026
- Billing: anomaly detection "runs on serverless compute and is billed as serverless DBUs under the DATA_QUALITY_MONITORING billing product." A line item, split out from serverless jobs usage. For results made from February 2026 on. - docs.databricks.com, 13 Sep 2026
- Launch framing, 12 December 2023: profile metrics "provide summary statistics of your data" and drift metrics "allow you to compare against your baseline tables," with an out-of-the-box customizable dashboard. - Databricks blog, 12 Dec 2023
Other head-to-heads
DataShield vs Qualytics
DataShield vs Qualytics: Qualytics scores and monitors the data an AI system reads. DataShield decides.
Same marketDataShield vs Snowflake DMFs
DataShield vs Snowflake DMFs: DMFs run scheduled data quality checks inside Snowflake. DataShield profiles,.
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, sources at the bottom.
Keep the monitor. Then see what a governed data plane adds. Classify a dataset. Break a live audit chain. Revoke an agent mid-session. 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 →