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 firm. It runs at Spark scale, in the warehouse you already pay for. The core is free and AGPL. You label 40 or 50 pairs: yes, no, or can't say. It builds a matcher from that. If the job is "find the duplicates in 80 million rows", go install it.
We build the rest of the platform, agent-first. An agent talks with a business user. It writes a spec. It walks a decision gate with them, step by step. Then it makes entity types, hierarchies, draft match configs, reference bindings and rules to check. All in one step. Nothing lands promoted. 143 of our MCP commands are for master data alone. After the match come the steward queue, the survivorship rules, and the quality gate a golden record must clear first. Plus the signed record of who approved the merge. We tokenize data at ingest. Agents query it as tokens, over MCP. Reversing a token is a locked, logged step. Plenty of teams keep Zingg for the heavy pass and use us for the rest.
The short version
Pick DataShield when
- Nobody on your team has built a mastering model before. An agent interviews a business user. It writes a spec. It walks a decision gate where each proposal carries a what, a why, an impact and the alternatives. You confirm or override. An override flips each dependent choice back for re-derivation. Then one transaction makes the model as drafts. What Ontology does.
- Agents read the golden records. A golden has to earn that read. Six quality axes with published weights and floors. A composite of 0.70 or better. A fail-closed consent veto. Reads come through views that mask in the view, not in a setting. How Auth does it.
- Stewardship is the actual work. Stewards dispose patterns, not items. A three-rung trust ladder promotes a pattern to auto-disposition. But only after 50 human approvals at a 98% rate, with zero dissents. One dissent demotes it. At the top rung, a deterministic sampler sends 10% of auto-disposed items to human audit.
- You have to show who approved a merge, months later. Governed actions land in a SHA-256 hash chain, with Ed25519-signed checkpoints. Verification returns clean, attested damage, or tampered. Erasure still works on top. Crypto-shred destroys the per-subject key. The chain still verifies once the subject is gone. Try the verifier in your browser.
Pick Zingg when
- You want it free, with the source. AGPL-3.0, about 1,200 stars. 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. We won't pretend otherwise.
- Active learning fits your team. Label 40 to 50 pairs. Get a model. Iterate. It's a genuinely good way to train a matcher. A data engineer who likes code in git will prefer it to a conversation.
- You need nickname dictionaries, company-name matching, standardize-and-match, or real-time. Those sit in their Enterprise tier. We ship no name dictionaries. Our matching is batch and on-demand, not a sub-second stream.
Bottom line: Zingg resolves entities. We help you build the model. We govern who reads the result. We keep the proof. Run both. Let the Spark job feed the queue.
Feature by feature
Vendor cells describe what Zingg's public docs, edition table and release blog say. As of the date above. Spot an error? Email support@myorg.ai. We'll fix it, and credit you.
| What matters | DataShield | Zingg | Edge |
|---|---|---|---|
| Standing up the model | An agent does it with you. mdm_project talks with a business user, in order. It writes a spec from the answers plus the live platform state. It shows a decision gate, step by step. Each choice carries a what, a why, an impact and the alternatives. You confirm or change it. A change ripples to each choice that depends on it. There is no accept-all button. One step then makes entity types, hierarchies, draft match configs, reference bindings and rules to check. Each is marked with an honest gate state. The generator never promotes a config. It never runs the match. It never skips the tests. 15 commands, no setup services. | You write the config. Label 40 to 50 pairs. Set fields and match types in Python or JSON. Run the Spark job. Look at the clusters. It's a clean developer loop. A data engineer will do fine in an afternoon. There is no talk, no gate, and no built model. | ◆ |
| Multidomain modelling | An open entity-type word list. You model your own domain. We don't ship a template you must bend to fit. Three wired matching modes per type. A People, Places and Things map that is a table row, not a fixed list. Hierarchies scope to a parent. Children resolve inside that parent's scope first, then cross-parent at a stricter bar. Links carry valid-from and valid-to dates. Domains carry an owner and a compliance rule set. There is no packaged Customer 360 here. | One entity type per job. The site names Customer 360, Supplier 360, KYC and fraud as use cases, not as shipped models. We found no hierarchy support, no link model, and no domain object in the docs. Knowledge graph sits in the Enterprise tier. | ◆ |
| Matching engine | Fellegi-Sunter probabilistic linkage, with Jaro-Winkler, Levenshtein, Soundex and Double Metaphone comparators. LSH blocking with a bucket cap. EM-trained m and u values, checked against a frozen holdout. A trained polarity flip is a hard refusal. An absolute-identifier tier routes ID conflicts to review, not to a merge. No config goes live without a green paired-gate test run, through the real scoring path. Auto runs sit behind a canary, then a ramp, then steady state. Pause and kill flags. Microbatch rollback. Checked against about 370,000 real public records, across three City of Chicago datasets, not just synthetic sets. | ML-based probabilistic matching in Community. Deterministic matching, standardize-and-match, explainability and match stats are Enterprise-tier. Their June 2026 essay argues classic probabilistic linkage has limits built in. That's a fair point to raise. | ◈ |
| Stewardship, trust and survivorship | A 29-command stewardship surface. Stewards review patterns with proof, plus a counter-proof scan that keeps the choice honest. So one human choice settles a whole pattern. A three-rung trust ladder promotes a pattern to auto-disposition. But only after 50 human OKs at a 98% rate, with zero dissents. One dissent demotes it. One OK means one human touch, never one item. Standing rules start staged. They need a second release step. Dry runs test blast radius, through the writer's own gate code. Five survivorship rules. Most-trusted uses measured overturn rates, not a hand-ranked list. Merge, unmerge, link and defer are all first-class moves. Link keeps two records apart when they only share a phone. | Cluster review and match notes are in the docs. We found no review queue, no assign or escalate step, and no survivorship rule set. Golden records come straight out of the job. | ◆ |
| Agent admission gate | A golden record must earn the right to be read by an agent. Six quality axes, with set weights and floors. A composite score of 0.70 or better. A fail-closed consent veto. Consent covers all six GDPR Article 6(1) lawful bases, across nine purposes. No basis on file means no permission. One shared rule runs the gate, on both the SQL and app read paths. So the two can't drift apart. Only the derived consent score crosses the masking line. The consent facts stay behind it. | Out of scope. A cluster table can be read by anything holding the connection string. Quality is whatever your pipeline claims. | ◆ |
| Ingestion, binding and classification | Six on-ramps: inline, URL and batch ingest, storage watch sources, a file repo. Plus a catalog link to a live PostgreSQL table, with no rows leaving it. Link once, and the model stays current on a set cadence. Choose auto, agent-review or steward-review refresh rules. Loads mark deleted source rows stale, and changed ones for a re-check. A weekly full pass cleans up deletes. On top of that: 129 field classes, with all 18 HIPAA Safe Harbor identifiers. Deterministic and repeatable, from a config digest. PostgreSQL today, not your whole estate. We are not an ETL tool and won't sell you one. | Reads whatever Spark reads, and that's a lot: all six of those same warehouses. That reach is real. We don't match it. What's missing is the model-building half: no refresh review, no field classing. Zingg matches. It won't tell you which column is a medical record number. | ◆ |
| MCP and agents | More than 200 MCP tools across Ontology, Auth, Corpus and Lighthouse. 143 commands are master data alone: mdm 99, stewardship 29, mdm_project 15. That's about a third of the whole agent surface. An agent can run the talk, work the gate, test and train a config. It can walk a review queue, merge, unmerge or read a golden record. All under one tool token. | The site 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, then wait. | ◆ |
| Audit evidence | SHA-256 hash chain. Ed25519-signed checkpoints, chained too. The verdict has three states: clean, attested damage, or tampered. Re-tampering an attested chain un-attests it, on its own. Each governance change also writes a before-and-after row, in the same step. Browser demo. | None in the docs. There is no audit page. Telemetry goes to Google Analytics. You can turn it off with collectMetrics: false. | ◆ |
| Agent authorization | Each governed tool call passes four checks first. A scope ceiling. A consented-tool allowlist. An access tier. A mid-session pull-back check. A pull hits on the next call. | No actor model. A Spark job runs as whoever launched it. Access control is the warehouse's job, not theirs. | ◆ |
| Break-glass | Scoped, time-boxed break-glass access. Admin plus IP-allowlist plus step-up gate. It auto-revokes and it is all logged. | Doesn't apply to a batch matching engine. | ◆ |
| GDPR erasure and consent | Crypto-shred of the per-subject key, plus ISO 27560 consent receipts. On top of that: a consent record. It keeps one live lawful basis per subject and purpose, add-then-replace. The audit chain still checks out after erasure. Actor identities in it are HMAC-committed. Golden version history lives on after deletion, as a marker with the reason and what came next. | No subject store and no key custody. So erasing one person from a merged cluster is a job for whatever tools you built yourself. | ◆ |
| Tokenization and data handling | Deterministic, join-preserving, vault-reversible tokens, set at ingest. 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 a measured shrink score. Matching runs on real source values. If a matching field is tokenized at rest, the run refuses with a clear error, instead of a mega-merge. Fields built from it, like phonetic and n-gram fields, inherit its PII verdict. So a name can't be rebuilt from its Soundex. | No tokenization and no masking. Zingg reads your columns as they are. Their security page says "No data leaves your environment". That's true, and it's a different promise. | ◆ |
| Scale and compute | DuckDB over Parquet with cost guardrails, on Postgres-backed storage. Matching runs batch and on-demand, not a live stream. We publish no record-count cap. We won't make one up. What we can show: about 370,000 real public records, across three datasets. No Spark, no spread-out cluster. | Runs natively in all six of those warehouses. "Millions of records" is their own wording. Spark is the right tool above a certain size. | ◇ |
| Deployment | Self-hosted in your own cloud or data center, or a single-tenant server we run for you. Docker images for Auth, Ontology, Corpus and Lighthouse. A signed deploy file checked by Guardian. | Self-hosted by design. Docker image on Spark 3.5.5, a Python wheel, or a native run in Snowflake at the Lite tier and up. | ◈ |
| Maturity and pricing | Auth, Guardian and Lighthouse are live now (Guardian and Lighthouse since April 2026). SOC 2 is planned, not attested, and we say so out loud. Listed pricing, 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 site. Community is free. Enterprise Lite and Enterprise are quote-only, with no listed prices. | ◇ |
◆ DataShield leads◇ Zingg leads◈ comparable
Zingg claims come from zingg.ai, the edition table, docs.zingg.ai and the release blog. Last checked 13 September 2026. We link them below. We don't paraphrase from memory.
Three things you get here that you won't get from a matching engine
A model an agent builds with you
Most MDM projects start with a consultant, a workshop and a spreadsheet of entities. Ours starts with a talk. An agent asks a user what they actually need to master. It reads the datasets you loaded. It writes a spec. You then work a gate, one choice at a time, in order. Change your mind about the entity model, and each choice below it reopens. The built objects land as drafts. A match config still has to train and pass its tests, before it goes live. What Ontology does.
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 log. We write each governed action into a hash chain with signed checkpoints. The checker says what broke. Not just that it broke. That's the shape EU AI Act Article 12 and HIPAA §164.312(b) reviewers look for. Try it in your browser, no signup.
Authority that changes mid-job
An analyst leaves on a Friday. Their agent is 20 minutes into a survivorship run. We re-check access on the next governed tool call, and it fails closed. The golden records that agent read came through views. They mask in the view, not in a setting. So the reader role has no grant on the base table at all. A batch matcher has no say here. It never knew who was asking. How Auth does it.
Where Zingg is genuinely stronger
Let's be fair. Zingg is good work, and it's free. The active learning loop is the nicest first day in this category. Label 40 to 50 pairs. Get a model. Test it on real data, instead of writing rules blind. It runs inside all six of those same warehouses. So no data moves, and no egress bill shows up. Version 0.6.0 added Databricks Unity Catalog support. 0.7.0 was a stability release. That's what a mature open-source project should look like. Their Enterprise tier ships things we simply do not have: nickname and company-name lists, standardize-and-match. Plus runs against data matched before, and a real-time build. If your bottleneck is matching 200 million rows on Spark, we are the wrong tool. They are the right one.
Here's the push-back. Their own blog spent June 2026 arguing this: the Fellegi-Sunter model has five limits built in that today's data can't dodge. We use Fellegi-Sunter too, so we read that essay closely. Our honest reply: the model is rarely where a project dies. Projects die in the six months after the match. Who decides the pairs the model won't call? How do you stop that person from drowning in them? Which source value wins, and who says so? Should an agent read the golden record, given what the subject agreed to? Where's the log an auditor will accept? We answer those with a pattern-grained queue, a trust ladder, five survivorship rules. Plus a quality and consent gate on each agent read, and a signed chain. Zingg's docs have a page about telemetry. No page about audit, access control or personal data.
That's not a knock on a matching engine. It's just what one is. Somebody still has to build the other half. That's 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 each 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. Verification tells tampering apart from insertion, deletion and truncation. Each in-place governance change also writes a before-and-after row, in the same step. Try it at /verify. Zingg: no, and it makes no such claim. We found no audit log in the docs at all. Whatever your own setup wrote is your whole evidence story.
What happens to a revoked agent mid-session?
DataShield re-checks access on each governed tool call. So a pull-back lands on the next call. If the run was an auto mastering job, a kill flag stops it, for good. A microbatch can roll back to its pre-image marker. Zingg has no notion of an agent or a session. A Spark job runs with the login it launched with, until it finishes. Killing it is a cluster act, 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 proof still checks out after the person is erased. The golden's version history lives on as a marker with the reason. Separately, a subject with no valid lawful basis is already left out of each agent read. 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. Then ask us the same.
Is DataShield a replacement for Zingg?
Often not, and we'd rather say so up front. If you already run Zingg on Spark, keep it. Feed the clusters into our stewardship queue. Apply survivorship there. Let agents read the goldens that clear the quality and consent gate. We compete when a buyer wanted a full MDM platform and found a library. Or when nobody on the team has built a model before, and the guided path beats the Spark ceiling. The real question: which layer does the duty land in?
Nobody here has built an MDM model. What does the first week look like?
With Zingg: read the docs. Define an entity in config. Label 40 to 50 pairs. Run the job. Look at clusters. Good if you have a data engineer to spare. With us: an agent talks with a business user, writes a spec. It hands back a gate, grouped by theme, in order. You confirm or change each choice. A change reopens everything that depended on it. Then one step makes the drafts. Nothing is promoted. Nothing resolves yet. The match config still has to train and pass a frozen test set. Ask us to run that live in the Demo Center. Don't just take our word for it.
We need deterministic matching and real-time. Who wins?
Read their edition table first. Community is probabilistic only. Deterministic matching, standardize-and-match, match stats and the real-time build sit in paid tiers, with no listed price. So "free" may not survive contact with your needs. On our side: probabilistic linkage, plus an absolute-identifier tier. It sends ID conflicts to a human, instead of merging them. A pattern born from a deterministic conflict can never earn auto-disposition. Real-time, we do not have. Get both quotes.
Does DataShield have SOC 2?
Not yet. SOC 2 is planned, not attested, and we won't say otherwise. Auth ships with a public threat model and a checker you can run. Guardian and Lighthouse have been live since April 2026. Design-partner terms include source escrow, so a small vendor isn't one point of failure. Details on the security page.
- Zingg's site headline is "Open Source Warehouse Native MDM For Humans And Agents". It lists Databricks, Snowflake, BigQuery, Redshift, AWS Glue, GCP and Microsoft Fabric. The site's own customer testimonials name Fortnum & Mason, Orthodox Union, Redica Systems and the Canadian Football League. The outcome figures there (the CFL's "10-15% of records consolidating into one profile", Redica's "90% better") are Zingg's customers' own claims. Not measurements we can verify. - 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. Star and fork counts are as GitHub displayed them on the date checked. - 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. An August 2026 post claims the Python API reached the top 10% of PyPI downloads. That's Zingg's own figure. - 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. Let an agent talk with you and build a draft model. Walk a stewardship queue. Break a live audit chain. Revoke an agent mid-session. Then 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 →