Head-to-head · updated 13 September 2026

DataShield vs Unity Catalog: who governs the data your agents touch off the lakehouse?

Unity Catalog is very good. At its job. It's the data catalog, and the permission system too. It's the lineage recorder. For the Databricks platform. Since 2025, it's grown. It now covers models and MCP servers. Agents too. Its hero line says: "Unified governance for data, apps and AI agents". Inside a Databricks estate: that's close to true. ABAC is live now. Governed tags drive row filters. And column masks. Lineage arrives for free. Databricks runs the compute. There's no extra license to buy.

DataShield isn't a lakehouse catalog. We won't pretend to be one. We're the authorization and proof layer for agents. We run on our own infrastructure, and use our own signing keys. We tokenize datasets at ingest. Agents query tokenized data over MCP. Turning a token back: a privileged step. Audited, too. Each checked call seals into a chain. A hash chain. You can verify it yourself. Below is the honest split. Databricks rows are included.

DataShield vs Unity Catalog at a glanceEight questions regulated buyers ask us. Scored from each vendor's public documentation. DataShield vs Unity Catalog at a glance Eight questions regulated buyers ask us. Scored from each vendor's public documentation. DataShield Unity Catalog Tamper-evident audit chain you can verify Authority re-checked on every tool call Break-glass access for agents GDPR erasure that keeps the chain valid One policy plane past the lakehouse Row and column policy on governed tables Column-level lineage across the platform Semantic layer your agents can query shipped partial / roadmap not offered Sources at the bottom of this page.

The short version

Pick DataShield when

  • Your agents reach past Databricks. Postgres, a vendor API, an S3 drop, a SaaS record. One rule plane, one log, for all of it.
  • An examiner will ask you to prove a log wasn't edited. Databricks stores its audit record as a system table it owns. It's still in Public Preview. Ours is a SHA-256 chain with signed checkpoints. Break it in a browser. Watch the verifier catch you. Run it.
  • You need to pull an agent's access mid-session. The very next call should fail closed.
  • You want the rule engine, the vault, and the proof running on your own hardware. You hold the keys. See the architecture.

Pick Unity Catalog when

  • Your data and compute live on Databricks now. It ships with Premium and Enterprise. No second vendor to buy, or renew.
  • You want row filters and column masks, driven by governed tags. They apply to tables, materialized views, and streaming tables, at query time. ABAC is live now. It's good. We don't do this.
  • You need column-level lineage, from a dashboard back to the source table. Databricks captures it. It runs the query. We can't see what we don't sit in front of.
  • You want a semantic layer your agents share with your analysts. Metric views define measures once. Genie Agents read them, with synonyms and display names attached. That's a real moat. We have nothing like it.

Bottom line: Unity Catalog governs the lakehouse. It governs everything Databricks runs. DataShield governs what an agent may do, anywhere. It keeps proof of that. The proof doesn't rest on the platform's word. In Databricks shops, we expect to run alongside.

Feature by feature

Competitor cells reflect Databricks' site and docs. As of the date above. Spot a mistake? Email support@myorg.ai. We'll fix it, and credit you.

What mattersDataShieldUnity CatalogEdge
Catalog scope and discoveryOntology registers a source. Over a live link. It scans it in place. With no row egress. It profiles assets and columns. PostgreSQL today, not your whole estate. Snowflake, BigQuery, Databricks, and S3 are planned. No handler yet. Field checks run deeper. 129 types, checksum validators. Fixed results, stamped with a config digest.One metastore, across each workspace. Cloud, and region too. Tables, files, functions. Models, agents, and MCP servers. Delta, Iceberg, and Parquet. This is the breadth we don't have.◇
Fine-grained access controlScope ceilings and access tiers. On MCP tool tokens. Plus quasi-identifier generalization. Dates to year, decade, or age band. ZIPs to 3 or 4 digits. Partial phones, SSNs, and emails. Each column gets its own cardinality-reduction score. Masking is a switch you flip. Not a default. We don't put row filters on Delta tables.ABAC is live now. Governed tags drive row filter and column mask rules. On tables, materialized views, and streaming tables. One rule can cover a whole catalog. DENY rules are still Beta.◇
Lineage and business semanticsTyped lineage, traced hop by hop. Access gets checked at each hop. It comes from the pipelines. The ones that own the ties. Not a stored graph. A business glossary built from entity types. No column-level lineage across a compute platform. And no metrics layer.Automatic column-level lineage. Across tables, notebooks, dashboards, and models. Metric views define measures and dimensions once. They serve SQL editors and dashboards. Genie Agents too. From the same definition.◇
Audit evidenceA 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 custody is a built seam. In Auth. So is HSM. Not a shipped link. Public demo.Rich audit events sit in the system.access.audit system table. The docs mark it Public Preview. We found no claim anywhere. Not that the records are hash-chained. Or signed, or checked on their own.◆
Agent authorizationEach checked tool call runs a sequence. A fixed one. Before dispatch. Auth gate, tool narrowing, token scope ceiling. Then a declared access tier. Then a revocation check. Then metering. Hand-offs use RFC 8693 token exchange. With a set scope ceiling.Grants and ABAC rules. On catalog objects. Plus RBAC on models, tools, and links. In Agent Bricks. Unity AI Gateway adds on-behalf-of runs. An MCP call runs under one identity. The requesting user. Their rights, not a shared login. Not a shared service login.◆
Break-glassScoped, time-boxed emergency access for agents. Admin plus IP allowlist plus step-up. Auto-revoking. It can't be quietly wiped. Not from the log.Not covered in the docs we read. Ask them.◆
GDPR erasureCrypto-shred of the subject's key material. Plus ISO 27560 consent receipts. Actor identities in the chain are HMAC-committed. The proof still checks out. Even after the subject is gone.Delete the rows. What erasure does to audit history? Not spelled out. Neither is what happens to data. Data copied out of tagged tables. Already copied out.◆
Tokenization and data handlingDatasets get tokenized at ingest. Agents query tokenized data over MCP. Turning a token back is privileged. And audited. Tokens are fixed, join-safe, and vault-reversible. Each lookup is logged, or refused.Masking and redaction applied at query time. By rule. Unity AI Gateway guardrails add PII detection. And redaction on model traffic. Listed as Beta, in the April 2026 launch post. We found no vault-reversible token setup. None with a checked detokenization path.◆
MCP and agentsMore than 200 MCP tools. Across Ontology, Auth, Corpus, and Lighthouse. Auth issues MCP tool tokens. With scope ceilings. Per-call counts tie back to the agent. The one that made the call.Managed MCP servers for Genie and AI Search. Plus SQL and Unity Catalog functions. A code interpreter too. Per-server OAuth scopes. With on-behalf-of user login. Claude and Cursor can connect today. The docs mark the feature Public Preview.◈
Reach beyond the platformPlatform-agnostic by design. Auth issues the token. The checked surfaces confirm it. On each call. Nothing needs a particular compute vendor.Lakehouse Federation gives "governed, read-only access to external data." Access rules sit at the table level. Catalog federation reaches Glue, Hive, and Snowflake. Plus Salesforce Data 360, and Palantir Foundry. Row and column rules stay a story. A Databricks-object one.◆
DeploymentSelf-hosted. In your own cloud or data center. Or on a dedicated single-tenant server. One we run for you. Docker images for Auth and Ontology. Corpus and Lighthouse too. With a signed deploy file Guardian checks.Databricks control plane on AWS. Or Azure, or GCP. With a customer-side data plane. The open-source Unity Catalog server is Apache 2.0. And self-hosted. But its own README says the APIs "should not be assumed to be stable". It carries a smaller feature set. Than the paid product.◆
Maturity and pricingLive 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 private firm. With a deep bench. And a long compliance record. No extra license. Unity Catalog rides on Premium. And Enterprise tiers. You pay for compute and storage. So you can't price the rules. Not on their own.◇

◆ DataShield leads◇ Unity Catalog leads◈ comparable

Databricks claims are drawn from two places: 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 platform catalog

A witness that isn't the defendant

Databricks writes the audit record. It stores it. It holds the keys to the storage. Its own docs discourage this. Moving that data off the platform. That's sound security advice. It also means one thing. The only witness is the system. The one under review. Our chain sits apart. In its own control plane. With its own signing keys. Edit a record in your browser. 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. With DataShield, the next checked tool call re-checks access. Right away. It fails closed. A permission change in a catalog. It doesn't reach a query already running. How Auth does it.

Governance that outlives the platform choice

Okera clients learned this in 2023. You pick a rules layer. The layer gets bought. Your rule model moves. To someone else's roadmap. Run the rule plane. And the proof plane. On your own hardware. That stops being your problem. How we deploy.

Where Unity Catalog is genuinely stronger

Start with the obvious. If your data sits on Databricks: Unity Catalog is there. Right now. It costs nothing extra. Turning on ABAC is a config change. Tag a column once. The rule follows it across a catalog. Lineage gets captured at column level. The platform runs the query, after all. No outside tool can match that. Not without sitting in the same place. Metric views are the underrated part. Define a measure once. Your dashboards compute it. So do your Genie Agents. The same way. Whoever owns the semantic layer owns more. What the agent believes the business means. Databricks noticed that before most people did. The Iceberg work is real too. They bought the format's makers. Then, in September 2026, they proposed shared specs. For portable policy and portable governance metadata. That's not how a vendor tries to lock the door.

Here's the push-back, and it's narrow on purpose. Those specs standardize how policy travels. And how metadata stays portable. Neither standardizes evidence integrity. Nobody in that proposal is signing anything. Databricks wrote this in the same post. Each catalog must show compliance. On its own. No admin should have to do that. Match up audit trails. Not across systems. We agree with the sentence. We disagree about one thing. Where the outside party sits. A system table in Public Preview. Owned by the platform. The one that ran the agent. That's telemetry. It's excellent telemetry. It's not the record. Not one you hand a regulator. Not with the claim. That nothing in it changed. And past the platform edge: Federation is read-only. With table-level controls. That's a long way off. From row and column rules. On your Postgres.

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 one thing. The record before it. Checkpoints are signed and chained. Verification tells deletion apart. From truncation and tampering. Try it at /verify. Unity Catalog: audit events land in the system.access.audit system table. The docs still mark it Public Preview. The events are detailed. Easy to query, too. Databricks doesn't claim they're hash-chained or signed. We went looking. Ask them to show you proof. 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 fast. On the very next call. Unity Catalog checks grants and ABAC rules. When a query runs. That covers a lot of ground. We found no description of that. A running agent session. Getting downgraded in flight. No access tiers for agents, either. 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 the subject's key material. It issues an ISO 27560 consent receipt. Actor identities in the chain are HMAC-committed. The chain still checks out. Even after the subject is erased. On the Databricks side, deleting rows is easy. What the docs don't cover? What erasure does to audit history. Or to data copied out of tagged tables. Ask both of us.

Is DataShield a Unity Catalog alternative, or does it replace it?

It's not a replacement. We'd be lying if we said it was. We don't put row filters on Delta tables, and we don't do column-level platform lineage. We have no metrics layer. What we replace is an idea. That the platform's own tables are proof enough. Most Databricks clients talk to us. They keep Unity Catalog. They add an outside layer. For agent authorization and tamper-evident proof. The longer case sits in our Unity Catalog write-up.

If we run the open-source Unity Catalog server, do we get the same governance?

No. And this one catches people out. The OSS project is Apache 2.0, and genuinely open. But its README warns the APIs "should not be assumed to be stable". The full feature surface stays in the paid platform. Ask Databricks directly which parts you keep. If you self-host the OSS server. ABAC, lineage, audit, the managed MCP servers. Then ask what your rules story is. For data that never touches Databricks. At all.

Does DataShield have SOC 2?

Not yet, and we won't say otherwise. Auth runs live in production. 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. So one small vendor stays safe. Never a single point of failure. Details on the security page.

Other head-to-heads

Same market

DataShield vs Microsoft Purview

DataShield vs Microsoft Purview: Purview governs the Microsoft estate end to end. DataShield adds per-call.

Same market

DataShield vs Snowflake Horizon

DataShield vs Snowflake Horizon: Horizon governs data inside Snowflake. DataShield adds reversible tokens,.

Same market

DataShield vs Amundsen

DataShield vs Amundsen: LF AI & Data archived Amundsen. That was September 2026. An honest self-hosted migration.

All

Every comparison

One honest scorecard per vendor, sources at the bottom.

Keep Unity Catalog. Then see what an outside layer adds. Break a live audit chain. Revoke an agent mid-session. Judge for yourself. Demo Center access is free with a work email.

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 →