Head-to-head · updated 13 September 2026
DataShield vs Zingg: is entity resolution the product, or the first step?
Zingg does one hard thing well. It matches records that belong to the same person or company, at Spark scale, inside the warehouse you already pay for. The core is free and AGPL. You label 40 or 50 candidate pairs yes, no, or can't say, and it trains a matcher from that. If the job is "find the duplicates in 80 million rows", go and install it.
A match is a step, though, not a system. Zingg hands you clusters. It does not hand you the queue where a steward settles the pairs the model won't call, the rule that picks which value survives, the masked view an agent is allowed to read, or the record of who approved the merge. We ship those. Datasets are tokenized at ingest; agents query tokenized data over MCP; detokenization is a privileged, audited operation. Plenty of teams keep Zingg for the heavy pass and use us for the rest.
The short version
Pick DataShield when
- You have to show who approved a merge, months later. Governed actions land in a SHA-256 hash chain with Ed25519-signed checkpoints, and verification returns clean, attested damage, or tampered. Try the verifier in your browser.
- Agents read the golden records. Ours come out through masked views that mask no matter how the deployment is set, and every governed tool call passes a scope ceiling and a fresh authority check. How Auth does it.
- Stewardship is the actual work. Review queues with assign, escalate and undo, five survivorship strategies, a blast-radius dry-run before a rule ships, and Population Stability Index drift monitoring on every promoted match config. What Ontology does.
- An erasure request lands on a merged cluster. Crypto-shred destroys the per-subject key, consent receipts are ISO 27560 shaped, and the chain still verifies once the subject is gone.
Pick Zingg when
- You want it free, with the source. AGPL-3.0, about 1,200 stars, and a Python API that reached the top 10% of PyPI downloads in August 2026.
- The match has to run on Spark, at volume, where the data already sits: Databricks, Snowflake, BigQuery, Redshift, Glue, Fabric. We run DuckDB over Parquet. Their ceiling is higher and we won't pretend otherwise.
- Active learning fits your team. Label 40 to 50 pairs, get a model, iterate. It is a genuinely good way to train a matcher and our config-first approach asks more of you up front.
- You need nickname dictionaries, company-name matching, standardize-and-match, or real-time. Those sit in their Enterprise tier. We ship none of the name dictionaries.
Bottom line: Zingg resolves entities. We master them, govern who reads them, and keep the proof. Run both, and let the Spark job feed the queue.
Feature by feature
Competitor cells describe what Zingg's public docs, edition table and release blog say as of the date above. If we've mischaracterised something, email support@myorg.ai and we'll correct it, credited.
| What matters | DataShield | Zingg | Edge |
|---|---|---|---|
| Audit evidence | SHA-256 hash chain with Ed25519-signed checkpoints that are themselves chained. The verdict is three-valued: clean, attested damage, or tampered. Re-tampering an attested chain un-attests it automatically. Browser demo. | None documented. The docs have no audit page. Telemetry goes to Google Analytics and can be switched off with collectMetrics: false. | ◆ |
| Agent authorization | Every governed tool call passes a scope ceiling, a consented-tool allowlist, an authority tier and a mid-session revocation re-check before dispatch. Revocation bites on the next call. | No actor model. A Spark job runs as whoever launched it. Access control is the warehouse's problem. | ◆ |
| Break-glass | Scoped, time-boxed emergency access, admin plus IP-allowlist plus step-up gated, auto-revoking and fully audited. | Not applicable to a batch matching engine. | ◆ |
| GDPR erasure | Crypto-shred of per-subject key material plus ISO 27560 consent receipts, and a consent-validity substrate that records a lawful basis per subject and purpose. The audit chain still verifies after erasure. | No subject store and no key custody, so erasing one person from a merged cluster is a job for whatever you built around it. | ◆ |
| Tokenization and data handling | Deterministic, join-preserving, vault-reversible tokens applied at ingest, plus quasi-identifier generalization (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. Matching runs on real source values, and a matching field that is tokenized at rest makes the run refuse, typed, rather than mega-merge. | No tokenization and no masking. Zingg reads your columns as they are. Their security page says "No data leaves your environment", which is true and is a different promise. | ◆ |
| MCP and agents | More than 200 MCP tools across Ontology, Auth, Corpus and Lighthouse. The mdm umbrella alone carries 99 commands, so an agent can open a review item, propose a merge or read a golden record under a tool token. | The homepage now says "For Humans And Agents", but we found no MCP server and no agent surface in the docs. Agents reach Zingg the way any job does: submit Spark work, wait. | ◆ |
| Matching engine | Fellegi-Sunter probabilistic linkage with Jaro–Winkler, Levenshtein, Soundex and Double Metaphone comparators, LSH blocking, EM-trained m and u parameters, and an absolute-identifier tier that routes identifier conflicts to review instead of merging them. Validated against Chicago open-data corpora, not only synthetic sets. | ML-based probabilistic matching in Community. Deterministic matching, standardize-and-match, explainability and match statistics are Enterprise-tier. Their June 2026 essay argues classical probabilistic linkage has structural limits, which is a fair argument to have. | ◈ |
| Scale and compute | DuckDB over Parquet with cost guardrails, on Postgres-backed storage. Good for mid-market estates. No Spark, no distributed cluster. | Runs natively in Databricks, Snowflake, BigQuery, Redshift, Glue and Fabric. "Millions of records" is their own wording, and Spark is the right tool above a certain size. | ◇ |
| Stewardship and survivorship | A 29-command stewardship surface: worklists, pattern-trust ladder, standing disposition rules, K% audit sampling, blast-radius dry-run, plus five declarative survivorship strategies and validation rules that gate golden publication. | Cluster auditing and match explanations are documented. We found no review queue, no assignment or escalation, and no survivorship rule set. Golden records come out of the job. | ◆ |
| Classification and catalog | 129 field classes including all 18 HIPAA Safe Harbor identifiers, deterministic and reproducible from a config digest, plus in-place scan and profiling of a live PostgreSQL source with no row egress. PostgreSQL today, not your whole estate. | Out of scope by design. Zingg matches; it does not tell you which column is a medical record number. | ◆ |
| Deployment | Self-hosted in your own cloud or data center, or a dedicated single-tenant server we operate. Docker images for Auth, Ontology, Corpus and Lighthouse, with a signed deploy manifest verified by Guardian. | Self-hosted by definition. Docker image on Spark 3.5.5, Python wheel, or native execution in Snowflake at the Lite tier and above. | ◈ |
| Maturity and pricing | Auth, Guardian and Lighthouse live in production, Guardian and Lighthouse since April 2026. SOC 2 not yet certified, and we say so. Published pricing model with a scoped instant quote. | Started 2020, still shipping: 0.6.0 in May 2026, 0.7.0 in August 2026. Named customers on the homepage. Community is free; Enterprise Lite and Enterprise are quote-only with no public prices. | ◇ |
◆ DataShield leads◇ Zingg leads◈ comparable
Zingg claims are drawn from zingg.ai, the edition comparison table, docs.zingg.ai and the release blog, last checked 13 September 2026. We link them below rather than paraphrase from memory.
Three things you get here that you won't get from a matching engine
A merge you can account for
Six months on, someone asks who merged two patient records and why. A Spark job leaves you a cluster table and a git history. We write each governed action into a hash chain with signed checkpoints, and the verifier says what broke, not just that something did. That is the shape EU AI Act Article 12 and HIPAA §164.312(b) reviewers look for. Try it in your browser, no signup.
Golden records agents can read safely
The masked golden views mask every time. They ignore the deployment posture on purpose, so a value captured in a relaxed setup can't leak later through the reader role. Agents query those views over MCP under a tool token with a scope ceiling. A raw match output has no such boundary: it is just a table, and anything with the connection string can read it. How Ontology handles it.
Authority that changes mid-job
An analyst leaves on a Friday. Their agent is 20 minutes into a survivorship run. We re-check authority on the next governed tool call and fail closed. A batch matcher has no opinion here, because it never knew who was asking. How Auth does it.
Where Zingg is genuinely stronger
Let's be fair. Zingg is a good piece of engineering and it is free. The active learning loop is the nicest onboarding in this category: label 40 to 50 pairs, get a model, iterate on real data instead of writing rules blind. It runs inside Databricks, Snowflake, BigQuery, Redshift, Glue and Fabric, so no data moves and no egress bill arrives. Version 0.6.0 added Databricks Unity Catalog support and 0.7.0 was a stability release, which is what a mature open-source project should look like. Their Enterprise tier ships things we simply do not have: nickname and company-name dictionaries, standardize-and-match, incremental runs against previously matched data, and a real-time architecture. If your bottleneck is matching 200 million rows on Spark, we are the wrong answer and they are the right one.
Here is the push-back. Their own blog spent June 2026 arguing that the Fellegi-Sunter model has five structural limits modern data can't ignore. We use Fellegi-Sunter, so we read that essay closely, and the honest reply is that the model is not where most projects fail. Most projects fail after the match. The docs tell the story: there is a security page about telemetry, and there is no page about audit logs, access control, or handling personal data in the records you just merged. That is not a criticism of a matching engine. It is a description of one. Somebody still has to build the queue, the survivorship rules, the masked read path and the evidence, and that somebody is usually two of your engineers for two quarters.
Questions worth asking both of us
These are the questions we'd want answered if we were buying. Ask them on every vendor call, including ours.
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 verification separates tampering from insertion, deletion and truncation. Try it at /verify. Zingg: no, and it doesn't claim to. We found no audit log in the docs at all. Whatever your orchestration wrote is your whole evidence story.
What happens to a revoked agent mid-session?
DataShield re-checks authority on every governed tool call, so revocation lands on the next call. Zingg has no notion of an agent or a session. A Spark job runs with the credentials it was launched with until it finishes, and killing it is a cluster operation, not a policy one.
How does GDPR erasure interact with the audit trail?
DataShield crypto-shreds the per-subject key and issues an ISO 27560 consent receipt. Actor identities in the chain are HMAC-committed, so the evidence still verifies after the person is erased. Zingg holds no subject keys, so an erasure request on a merged cluster falls to you. Ask them how they'd unwind a golden record built from five sources, and ask us the same.
Is DataShield a replacement for Zingg?
Usually not, and we'd rather say so. If you already run Zingg on Spark, keep it. Feed the clusters into our stewardship queue, apply survivorship there, and let agents read the masked golden views. We compete only when a buyer wanted the whole mastering workflow and found a library instead. The real question is which layer the obligation lands in.
We need deterministic matching and real-time. Who wins?
Read their edition table first. Community is probabilistic only. Deterministic matching, standardize-and-match, match statistics and the real-time architecture sit in paid tiers with no published price, so "free" may not survive contact with your requirements. Our matching is one engine either way: probabilistic linkage plus an absolute-identifier tier that sends identifier conflicts to a human instead of merging them. Get both quotes.
Does DataShield have SOC 2?
Not yet, and we won't imply otherwise. Auth ships with a public threat model and a verifier you can run. Guardian and Lighthouse have been in production since April 2026. Design-partner terms include source escrow, so a small vendor isn't a single point of failure. Details on the security page.
- Zingg's homepage headline is "Open Source Warehouse Native MDM For Humans And Agents", listing Databricks, Snowflake, BigQuery, Redshift, AWS Glue, GCP and Microsoft Fabric, with named customers including Fortnum & Mason, Redica Systems and the Canadian Football League. — zingg.ai homepage, 13 Sep 2026
- Repository description: "Scalable master data management, identity resolution, entity resolution, and deduplication using ML". AGPL-3.0, about 1.2k stars and 176 forks, written in Java, Scala and Python. — GitHub, zinggAI/zingg, 13 Sep 2026
- Community edition is probabilistic matching only. Zingg Unique ID, incremental runs, Verify Blocking and native Snowflake run start at Enterprise Lite; deterministic matching, standardize-and-match, match statistics, nickname and company-name matching, knowledge graph, explainability and real-time architecture are Enterprise. — Zingg edition comparison, 13 Sep 2026
- Zingg's security and privacy page covers deployment and telemetry: "No data leaves your environment" and "Zingg does not capture any input data and will never do so". It documents no audit log, access control model or PII handling. — Zingg docs, security and privacy, 13 Sep 2026
- 2026 releases: 0.6.0 (8 May 2026) added Databricks Unity Catalog support, Spark 3.5.5 and a lighter Python wheel; 0.7.0 (10 Aug 2026) was "A More Stable, More Usable Zingg". A 1 June 2026 essay argues the Fellegi-Sunter model has five structural limits. — Zingg blog, 13 Sep 2026
- EDPB names pseudonymization as a GDPR risk mitigation for AI models. — EDPB Opinion 28/2024
Other head-to-heads
DataShield vs Senzing
Real-time entity resolution in a box, versus the workflow around it.
AdjacentDataShield vs Tilores
An identity resolution API is fast. Then the steward shows up.
DirectDataShield vs Reltio
Cloud MDM suite pricing, against a self-hosted stack with evidence.
AllEvery comparison
One honest scorecard per vendor, including the rows we lose.
Keep Zingg for the matching. Then see the rest run in your browser: break a live audit chain, revoke an agent mid-session, walk a stewardship queue, and decide. 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 →