Entity Resolution Software: 50+ Tools Compared

Last reviewed: November 2026

Disclosure: we build Zingg, which appears in this list. We describe every tool, including our own, by what it does and where it fits, and we say where another tool is the better choice. Vendors change quickly; if you spot something out of date, tell us and we'll correct it.

This is a map of the entity resolution market: over 50 tools in six categories, from engines that run inside your data platform to MDM suites, customer data platforms, identity data providers and graph databases.

If you're still working out what you need, start with our buyer's guide to choosing entity resolution software. It covers the eight questions that decide fit. This post applies them to the tools.

How each tool is described:

• Where it runs: where matching is computed. This could be your data platform, servers you operate, or the vendor's cloud.
• Where data lives: where records and results are kept. This could be your tables, or the vendor's own store. See step 3 of the buyer's guide for why the difference matters.
• Good fit when and less suited when: the situations where the tool is the right choice, and where something else would serve you better.
  
  ‍

At a glance

1. Engines that run inside your data platform

Zingg

Zingg is an entity resolution engine for Databricks, Snowflake, Microsoft Fabric, Google Cloud and AWS. It learns which records to compare and what counts as a match from a few dozen labelled pairs, weighing all the fields of a record together, so there are no blocking rules or field thresholds to tune by hand. Labels can come from an interactive session, or from a table or file. The core is open source.

Zingg Enterprise adds:

• exact-match rules in the same run
• a persistent ZINGG_ID
• incremental runs that handle additions, updates and deletions, merging and splitting clusters automatically while keeping IDs stable
• explainable matches, showing which records formed a cluster, which didn't, and why
• native Snowflake execution
• commercial support

Jobs are configured in JSON or through the Python API, run as named steps, and write results to tables. Agents can operate Zingg and read its output as easily as engineers can.

• Where it runs: on your Spark or Snowflake compute.
• Where data lives: in your tables.
• Good fit when: a data team, or the agents it runs, wants resolution inside its own pipelines, for any entity.
• Less suited when: data stewards need a point-and-click interface and review workflows to approve matches and manage golden records, or an application needs record-by-record matching through a real-time API.
• Try it: Docker quick start.

Splink

Splink is an open-source Python library from the UK Ministry of Justice. It uses Fellegi-Sunter probabilistic matching, estimating its parameters without labels. You define the comparisons and the blocking rules. It can also score small batches of new records against an existing model.

• Where it runs: on your DuckDB, Spark or PostgreSQL.
• Where data lives: in your tables.
• Good fit when: your team is comfortable configuring probabilistic models in Python. It's widely used in the public sector and in research.
• Less suited when: you need vendor support, SLAs or a commercial roadmap. Merging and splitting clusters as records change, and retuning blocking rules as data grows, are left to you. Splink vs Zingg.

AWS Entity Resolution

AWS Entity Resolution is a managed AWS service with rule-based matching (exact and fuzzy), a pre-built ML model, and matching against data providers' reference data. With rules, new records are compared against existing ones as they arrive, so you pay only for incremental processing. Automated incremental processing isn't available with ML-based matching.

• Where it runs: AWS-managed compute.
• Where data lives: your S3, read through Glue tables.
• Good fit when: you're on AWS and have straightforward customer matching that you'd rather hand to a managed service.
• Less suited when: you need incremental runs with ML matching, or your data lives outside AWS.

Google Cloud Entity Reconciliation

Google Cloud Entity Reconciliation is part of Google's Enterprise Knowledge Graph, and it's still a pre-GA product with limited support. Input must be BigQuery tables, mapped to predefined schema.org types such as organisations, people and local businesses. Each job reprocesses everything and writes a fresh snapshot table. Cluster IDs can be kept stable across runs by pointing a job at the previous results table.

• Where it runs: Google-managed compute.
• Where data lives: your BigQuery.
• Good fit when: your data is in BigQuery and your entities fit Google's predefined types.
• Less suited when: you have other entity types, need incremental processing or control over matching, or need a generally available service.

2. Standalone entity resolution engines and matching tools

Senzing

Senzing is a proprietary SDK that resolves record by record in real time, using models pre-tuned for people and organisations. As new or changed records arrive, it re-evaluates earlier decisions as well as resolving the new ones. Its documentation includes a section on agentic entity resolution.

Fields that don't map to one of Senzing's predefined features are stored as payload but not used for matching.

• Where it runs: the Senzing SDK on servers or cloud VMs you operate.
• Where data lives: a Senzing repository in a supported database: PostgreSQL, Aurora PostgreSQL, SQL Server, Azure SQL, Oracle, MySQL, or SQLite for small volumes.
• Good fit when: you need real-time resolution of people and organisations, especially in investigations and intelligence.
• Less suited when: your data has entities or fields outside its predefined features, or you want to avoid running and syncing a separate repository. Senzing vs Zingg.

Tilores

Tilores is a real-time engine accessed through a GraphQL API. It matches records as they arrive using explicit, auditable rules with fuzzy comparisons, against a schema you configure.

• Where it runs: Tilores compute, as a managed service or deployed into your own AWS account.
• Where data lives: Tilores' own entity store.
• Good fit when: an application needs an up-to-date entity graph behind an API, for example in onboarding or KYC.
• Less suited when: you'd rather matching was learned than written as rules, or want to avoid running a separate entity store. Tilores vs Zingg.

Data Ladder (DataMatch Enterprise)

DataMatch Enterprise is a no-code data quality and matching tool covering profiling, cleansing, deduplication and golden records. You choose from exact, fuzzy, phonetic, probabilistic and domain-specific algorithms, each with adjustable weights and thresholds. It runs as Windows desktop or server software, or in Docker on Linux, on-premises or in the cloud, and recently added a REST API.

• Where it runs, and where data lives: DataMatch desktop or server, on-premises or in your cloud.
• Good fit when: data quality or operations teams want to configure and review matching through a visual interface, without code.
• Less suited when: you want matching to run inside your data platform's pipelines, or want matching learned rather than configured algorithm by algorithm.

WinPure Clean & Match

WinPure is a no-code data quality and matching platform that runs inside your own infrastructure. It combines traditional fuzzy matching with automated rule recommendations, an AI entity resolution module, and a graph view for reviewing matches. Its Entity AI module is built on Senzing's engine. It also offers REST APIs and an MCP connection for AI assistants.

• Where it runs, and where data lives: on-premises, on desktops or servers.
• Good fit when: teams want desktop-friendly cleansing and matching with data kept in-house.
• Less suited when: you want resolution inside your data platform at warehouse scale.

Melissa MatchUp

MatchUp is Melissa's deduplication tool for contact data. It pairs Melissa's knowledge of names and addresses with more than 20 fuzzy matching algorithms, configured through match codes. It's available in Melissa Unison, SQL Server Integration Services and Pentaho, as well as through APIs and a cloud service.

• Where it runs: inside your ETL tool, or through Melissa's APIs.
• Where data lives: in your databases, or with Melissa if you use its batch service.
• Good fit when: you're deduplicating names and addresses, especially alongside address verification.
• Less suited when: your entities go well beyond contact data.

Babel Street Match (formerly Rosette)

Babel Street Match does multilingual name matching, combining machine learning with linguistic algorithms. It can match on a name alone, or on a name plus other attributes such as address, date of birth or ID number. It's delivered as an SDK and API, and is often built into screening and investigation products.

• Where it runs: embedded in your application, or in Babel Street's cloud.
• Good fit when: you need names matched accurately across languages and scripts, as in sanctions screening, KYC and investigations.
• Less suited when: you need full record resolution and clustering across whole datasets, rather than name matching inside an application you build.

NetOwl EntityMatcher

NetOwl EntityMatcher resolves identities using name similarity combined with attributes such as date and place of birth, address and nationality. Its name matching is probabilistic, with rules learned from large collections of real-world name variants. It's available on-premises with a REST API.

• Where it runs: on-premises, through its API.
• Good fit when: you need multicultural name matching for intelligence, compliance or fraud work.
• Less suited when: your entities aren't mainly people or organisations.

Interzoid

Interzoid offers matching APIs based on similarity keys: each record gets a generated key, and records with the same key are treated as matches. It offers keys for company names, personal names and addresses, and can run matching jobs directly against databases such as Snowflake.

• Where it runs: Interzoid's cloud APIs, called per record or per batch.
• Good fit when: you need quick, lightweight company or name normalisation inside existing pipelines.
• Less suited when: you need multi-field resolution with clusters and persistent IDs.

3. Master data management suites

MDM suites do entity resolution as one part of a larger job: golden records, survivorship, hierarchies, stewardship and governance. How well they match varies a lot. Some include matching engines built for it. Others mainly use match rules you configure, sell matching as an add-on, or rely on partner products. If your data is messy, multilingual or lacks identifiers, test the MDM's matching on its own before you judge the suite as a whole.

Reltio

Reltio is cloud SaaS MDM, and part of SAP since SAP completed its acquisition in May 2026. It remains available as a standalone product. It has three ways to match:

• rule-based matching with exact and fuzzy comparisons
• an active-learning ML model trained by reviewing pairs
• pre-trained LLM-based models that match without training

The three can run together. Matching is event-driven, running whenever a record is created or updated. For very large loads, Reltio advises temporarily removing match rules, and changing match rules means rebuilding the match tables and reprocessing every profile.

• Where it runs, and where data lives: Reltio's cloud.
• Good fit when: you want SaaS MDM with stewardship for business users.
• Less suited when: you'd rather not ingest data into a vendor cloud and sync it back. Reltio vs Zingg.

Informatica MDM

Informatica MDM runs in Informatica's Intelligent Data Management Cloud. Informatica has been part of Salesforce since November 2025. It matches with match-and-merge rules, using fuzzy match keys to find candidates, with CLAIRE AI assistance. Machine-learning matching is described in partner material for its cloud MDM.* It covers hierarchies, stewardship, governance and 360 applications. Its batch match jobs compare new and updated records against every record already in the hub.

• Where it runs: Informatica's cloud.
• Where data lives: the Informatica MDM hub.
• Good fit when: you're already standardised on Informatica.
• Less suited when: you want to avoid ETL into a hub and managing consistency with your other systems. Informatica vs Zingg.

Tamr

Tamr is MDM that matches with machine learning and human-in-the-loop stewardship. Its hosted SaaS is built on Google Cloud, and it can also run in your own cloud environment. It can run continuously, from dataset upserts through mastering to export, and Tamr IDs persist as long as source primary keys and dataset names stay the same.

• Where it runs, and where data lives: Tamr's SaaS, or your own cloud.
• Good fit when: you want ML-driven mastering with stewardship.
• Less suited when: you'd rather not define blocking terms and retune them as data grows. Tamr vs Zingg.

CluedIn

CluedIn is Azure-native MDM that matches with deterministic and probabilistic rules, and markets itself as agentic MDM. Incoming data either creates new golden records or adds to existing ones, through streaming or scheduled ingestion. Golden records can be exported to OneLake in Microsoft Fabric and to other stores such as Snowflake and BigQuery.

• Where it runs: in your Azure tenant, or as managed SaaS.
• Where data lives: CluedIn's own store, with exports to your lake or warehouse.
• Good fit when: your organisation is Microsoft-centric.
• Less suited when: you're not on Azure. CluedIn vs Zingg.

LakeFusion

LakeFusion is MDM built natively on Databricks. It matches with deterministic rules, then a learned model, and sends uncertain pairs to an LLM, with survivorship and stewardship on top.

• Where it runs, and where data lives: your Databricks.
• Good fit when: you're Databricks-only and want an MDM application on your lakehouse.
• Less suited when: you run more than one data platform, or need predictable cost per run. It's a newer vendor, founded in 2024.

Other MDM suites

• Semarchy xDM: multi-domain MDM and data hub, configured with match rules.
• Profisee: MDM built around the Microsoft ecosystem (Azure, Fabric and Purview), with configurable matching strategies.
• Stibo Systems STEP: multi-domain MDM with roots in product information management.
• IBM Match 360: IBM's matching and MDM service on Cloud Pak for Data, building on IBM's probabilistic matching engine.
• SAP Master Data Governance: MDM for SAP-centric estates, focused on governance workflows.
• Oracle Customer Data Management: customer MDM for Oracle application estates.
• TIBCO EBX: multi-domain MDM and reference data management.
• Ataccama ONE: data quality, governance and MDM in one platform.
• Precisely: data integrity tools, with Trillium-heritage matching plus EnterWorks MDM.
• Syniti: data migration and data quality, often used in SAP programmes.

4. Platforms where resolution serves a specific outcome

Quantexa

Quantexa is a decision intelligence platform for financial crime, risk and investigations. Its entity resolution uses configurable, pre-trained models and has no predefined data model, so entity types are configured per deployment. It can resolve in batch, in real time, or dynamically at the moment of a request.

• Where it runs: the Quantexa platform, built on Spark.
• Where data lives: an object store (such as HDFS, ADLS, S3 or GCS) alongside Elasticsearch or OpenSearch.
• Good fit when: you're a bank or insurer that wants an end-to-end investigation platform.
• Less suited when: you only need resolved entities back in your own data platform. Quantexa vs Zingg.

Amperity

Amperity is a CDP with identity resolution built in. It scores record pairs with a machine-learning classifier alongside deterministic rules, after a built-in blocking step that is tuned with Amperity. Its full resolution runs daily. A newer incremental mode only attaches new records to existing profiles or creates new ones; it doesn't re-evaluate, merge or split existing profiles. Amperity Bridge shares data with Databricks, Snowflake and BigQuery without copying it.

• Where it runs, and where data lives: Amperity, with zero-copy options.
• Good fit when: your marketing and CX teams want resolution and activation in one product.
• Less suited when: you need entities other than customers. Amperity vs Zingg.

Hightouch

Hightouch is a composable CDP whose identity resolution runs in your warehouse and writes the identity graph back to a table there. Matching is deterministic by default. Merge rules can add fuzzy and Soundex comparisons, grouped into rule sets that run strictest first, and limit rules stop unrelated records collapsing into one identity. It can also resolve households and business accounts.

Scale: run time depends on data volume, rule complexity and the warehouse compute available. Later runs are incremental, but changing rules or input models triggers a full rerun. IDs stay stable across incremental runs unless two identities merge. We found no public benchmarks at large volumes, so test your fuzzy rules on your full data.

• Where it runs, and where data lives: your warehouse.
• Good fit when: marketing and data teams want a rules-based identity graph in their own warehouse, feeding activation.
• Less suited when: you want matching learned rather than written as rules, or entities beyond customers, households and accounts. It requires a Business tier plan.

Other CDPs and customer platforms

Most of these mainly stitch on identifiers. Some add fuzzy match rules.

• Salesforce Data Cloud: unifies profiles with exact and fuzzy match rules.
• Adobe Real-Time CDP: builds a deterministic identity graph from known identifiers.
• Microsoft Dynamics 365 Customer Insights – Data: unifies profiles with deduplication and match rules.
• Twilio Segment (Unify): merges profiles on user IDs, emails and anonymous IDs.
• RudderStack Profiles: ID stitching inside your own warehouse.
• Treasure Data: CDP that unifies profiles on identifiers.
• Bloomreach: commerce CDP that merges profiles on identifiers.

5. Identity data providers

These providers match your records against their own large databases of people, households or businesses, and return a persistent identifier. They help most when your own data is thin. The trade-off is that your records need to go to the provider, or be matched in a clean room.

• LiveRamp: RampID, an identity graph for marketing and data collaboration.
• Experian: consumer and business identity data and matching.
• TransUnion: identity resolution for marketing and risk.
• Equifax: identity data for risk, fraud and verification.
• LexisNexis Risk Solutions: LexID identity linking for risk, fraud and compliance.
• Acxiom: consumer identity resolution for marketing.
• Epsilon: consumer identity graph for marketing.
• Dun & Bradstreet: business entity matching to D-U-N-S Numbers.
• Moody's (Orbis): company and ownership data for business entity matching and KYC.
• Unified ID 2.0 and ID5: shared AdTech identifiers that replace third-party cookies. These are frameworks rather than matching software.

6. Graph and identity-graph infrastructure

These products store and query entity relationships. They provide low-level building blocks rather than finished entity resolution, so you build the resolution logic from their constructs yourself:

• the queries or algorithms that generate candidate pairs (your own blocking)
• the similarity measures, and how they're computed
• the thresholds
• how results are clustered
• how IDs stay stable when the graph changes

Identity stitching on shared identifiers is straightforward to express as graph traversal. Deciding that two records with different identifiers are the same entity is work you design and maintain. These products work best downstream of a resolution engine, storing and serving the graph it produces.

• Neo4j: a graph database with query and similarity functions you assemble into a resolution workflow. Neo4j and Zingg.
• PuppyGraph: a graph query engine that runs over your existing tables, so you can query them as a graph without ETL.
• Aerospike Graph: a low-latency graph database for AdTech and martech identity graphs.
• TigerGraph: a distributed graph database used for fraud and identity analytics.
• Amazon Neptune: AWS's managed graph database.
• Linkurious: graph visualisation and investigation software.
• DataWalk: a platform for investigations and link analysis.

Open-source libraries

Zingg and Splink are covered above. For dedupe, recordlinkage, JedAI and others, see Top 10 Open Source Entity Resolution Tools. Most libraries leave blocking, thresholds and keeping clusters current for you to design.

FAQ

Which entity resolution tools run inside my data warehouse or lakehouse?

Zingg (Databricks, Snowflake, Fabric, Google Cloud and AWS), Splink (DuckDB, Spark, PostgreSQL), LakeFusion (Databricks) and Hightouch's identity resolution (your warehouse) all compute and write results inside your platform. AWS Entity Resolution and Google Cloud Entity Reconciliation are managed services that read from and write to your cloud storage.

Which entity resolution tools are open source?

Zingg's core and Splink are open source. For more libraries, see our open source list.

Which tools resolve entities in real time?

Senzing and Tilores resolve record by record as data arrives. Reltio matches whenever a record is created or updated. Quantexa can resolve dynamically at request time.

Which tools handle entities beyond customers?

Zingg, Splink and the multi-domain MDM suites (Reltio, Informatica, Tamr, CluedIn, LakeFusion) handle suppliers, products and other entities. Senzing, Google Cloud Entity Reconciliation and most CDPs focus on people and organisations, or on customers.

How do I choose between them?

Start with the buyer's guide. Which job you need done (stitching or resolution), which entities you have, and where your data must stay will narrow this list quickly.

Try entity resolution on your own data

The fastest way to apply this list is to test a tool on your own records. Zingg's open-source core runs locally in minutes with the Docker quick start, and the code is on GitHub. If you need incremental runs, persistent IDs or explainable matches, talk to us about Zingg Enterprise.

* Not confirmed in the vendor's own public documentation at the time of review.

Changelog: November 2026 — first published.