How to Choose Entity Resolution Software: A Buyer’s Guide

Last reviewed: November 2026

Published by Zingg. We build one of the tools you might evaluate, and two of our design choices shape this guide: Zingg runs on your own data platform and writes results to your tables, and it learns matching from examples you label. Where a criterion follows from those choices, we say so, and we say when another approach is the better fit. For open-source options, see Top 10 Open Source Entity Resolution Tools (2026).

Short answer: the right entity resolution tool depends on your situation. Twelve questions decide which one fits, starting with whether you want an identity foundation for the enterprise or a tool for one application. Any of them can rule a tool out. For most teams the deciding factor is accuracy: how well a tool matches your own records. For some it is scale, and for others it is where data must stay, which entities they need, or whether they need real time. This guide walks through each one, ending with a checklist for proving a shortlisted tool on your own data.

A note on terms: entity resolution and identity resolution are largely the same technique. “Identity resolution” is usually used when the entities are people: customers, patients, citizens. “Entity resolution” is the more general term, covering people as well as companies, households, suppliers, products, locations and anything else that appears in more than one record. This guide uses “entity resolution” throughout, because most organisations eventually need to resolve more than people.

The twelve questions

Any of these can rule a tool out, and which one does depends on your situation. For most teams the deciding factor is accuracy: how matching works (question 6), checked on your own records before you commit (question 12). For some, scale is a hard limit from the start (question 7). Where matching runs and where data must live (questions 4 and 5) settle it for teams that can’t copy sensitive data, and real time (question 9) for decisions that can’t wait for a batch. The first question is about your architecture roadmap, and it shapes how you weigh all the others.

An identity foundation, or one application?

Before the technical questions, decide where entity resolution sits in your architecture roadmap. Most forward-looking organisations treat it as a foundation: an identity layer of resolved customers, suppliers, products and locations, with one ID for each, shared by every application, report, model and agent.

They usually start with one application, then add agents and other parts of the business on top. Because matching is done once, each new use starts from entities that are already resolved, and teams never end up with competing versions of the customer. As AI agents take on more work, this layer is what they reason over: an agent can only act on “this customer” if every system agrees who the customer is.

A foundation belongs with the rest of your shared data. It lives on your data platform, has a clear owner, keeps IDs stable, and has room for more entity types and sources as teams join.

Some teams need entity resolution for one application only, often run by a business team: a CRM, a marketing audience, a loyalty programme or a compliance check. If the need is contained and unlikely to spread, the matching built into that application, or a point solution, may be enough. The cost shows later, if other teams build their own and the versions have to be reconciled.

Ask:

• Is entity resolution on your architecture roadmap as shared infrastructure, or as a feature of one application?
• Will other teams, systems and agents rely on the same IDs in the next few years?
• Who will own the resolved entities, and who decides what counts as a match?
• Can the tool take on more entity types and sources as other teams join?

Which job do you have?

Two different jobs are both called “identity resolution”, and most tools are built mainly for one of them.

Identity stitching links records that share an identifier you trust: the same email, phone number, login, device ID or hashed email. Chain shared identifiers together and you get an identity graph. Stitching is fast, deterministic and easy to explain. It’s the right approach when your identifiers are reliable, and it’s how most customer data platforms and AdTech identity graphs work.

Entity resolution decides which records belong to the same real-world entity when identifiers are missing, inconsistent or can’t be trusted. It compares names, addresses, dates and other attributes, including typos, abbreviations and out-of-date values. “Jon Smith, 12 Wood St” and “John Smith, 12 Wood Street”. “Acme Corp Ltd” and “ACME Corporation”.

Stitching has two limits worth knowing:

• It misses records with no shared key. A customer who used a different email, or a supplier entered with a typo, never gets linked.
• It over-merges on bad keys. Shared family emails, recycled phone numbers, shared devices and placeholder values (“test@test.com”, “0000000000”) can join unrelated people into one identity.

Most organisations need both: stitch on the identifiers you trust, and resolve the rest. Customer data with logins and loyalty IDs leans towards stitching. B2B accounts, suppliers, products, offline customers and records merged from acquisitions lean towards resolution. When you evaluate a tool, ask which of the two it does, and how it prevents a bad identifier from merging unrelated records.

Which entities?

For many teams this question narrows the field quickly. Many tools only resolve people, only customers, or only the predefined fields of people and organisations. If you also need households, companies, suppliers, products, locations or assets, a large part of the market drops out.

Check that a tool can match on the fields that actually describe your entities, not only the fields it was built for. Some tools store fields they don’t recognise but ignore them for matching. For product or supplier data, the fields that decide a match (part numbers, specifications, tax IDs, brand names) are often exactly the ones a people-focused tool doesn’t use.

Where must matching run?

Where matching runs and where data lives are two separate questions, and each has its own consequences.

Where matching runs is about compute: your own data platform, servers you operate for the vendor’s software, or the vendor’s cloud. When matching runs on the platform you already use:

• Your controls apply automatically. Access policies, masking, encryption and audit logging are the ones your team already maintains, with no second system to configure.
• It’s part of your existing pipelines. Jobs run in the same orchestration, scheduling, version control and CI as the rest of your data work, so resolution is one more step in a pipeline rather than a separate process to coordinate.
• It scales with compute you already manage. You size it the way you size other workloads, and the cost shows up on a bill you already watch.

Where must data live?

Where data lives is about the store: your own tables, or the vendor’s repository, hub or entity store. When results land in your own tables:

• They’re immediately useful. Analysts join resolved entities to orders, tickets and events with plain SQL. Models use them as features. Agents and applications read them through interfaces your team already supports.
• There’s no lag or drift. You don’t wait for a sync, and you don’t reconcile two versions of the truth when a sync fails.
• Residency is simpler. Data stays in the region and account you’ve already approved.
• You keep what you’ve built. The resolved entities and their IDs stay in your tables if you change tools later.

Separate systems earn their place too. Real-time lookup APIs and stewardship screens usually come with a vendor’s own compute and store. The trade-off is that you load data into them and have to manage data consistency between the copies, through custom pipelines or other mechanisms. If security, residency or cost rules out copying data, this question alone decides much of your shortlist.

This is one of Zingg’s design choices: it runs on your data platform and writes to your tables. If you need a hosted real-time lookup, a separate system may suit you better.

How should matching work?

Tools reach a match decision in very different ways: rules you write, models pre-trained by the vendor, models learned from examples you label, or a language model for the hard cases.

Writing your own matching logic is harder than it looks. The usual approach is field by field: pick a fuzzy function for each field, set a threshold for each, and combine them with and/or rules. It works on the first test set. Then real data arrives, and you’re left refining the rules indefinitely, because whether two records match rarely depends on any one field. It depends on how all the fields agree and disagree together.

An example. Four customer records:

B is Michael using his work email. C is Michael after he moved. D is his father, who shares his name and lives at the same address.

Field-level rules can’t get all three right at once:

• “Name and address match” joins A, B and D. It merges Michael with his father, and still misses C.
• “Name and email match” joins A and C. It misses B, and says nothing about D.
• Combining the two with “or” brings in C, but D is still merged.
• Adding “and date of birth must match” fixes D, until you meet records where the date is missing or entered in another format.

Every fix is another rule to maintain, and every new data source brings its own exceptions.

The underlying pattern is simple to state and hard to write as field-level rules:

• A different email or address on its own is weak evidence; people change both.
• A clearly different date of birth is strong evidence, even when name and address agree.
• A missing value is neither agreement nor disagreement.

Approaches that learn from labelled examples of whole records pick this up directly, because they weigh all the fields together instead of judging each against its own threshold.

This is Zingg’s other design choice: it learns matching from examples you label.

What labelling costs. If a tool learns from labels, find out how many it needs. Some approaches need tens of thousands of labelled pairs before they match well, which makes them impractical for most teams, and each new entity type or source can mean starting again. Others use active learning to choose the pairs that teach the model most, and need far fewer. Ask how many labelled pairs a tool needs for each entity type, who does the labelling, and how long it takes.

When a pre-trained or principle-based engine is the better fit. Learned matching is not always the right answer. Some engines ship with the matching logic already built in, with no labelling step: you load records and get entities. That wins when you have no time or no one to label, when your entities are mostly people and organisations with standard attributes, or when you need very low-latency lookups at runtime. The trade-off is less control over what counts as a match in your domain. If your data has unusual fields (part numbers, specifications, local naming conventions), or your definition of “the same” differs from the vendor’s, you have fewer levers. Plain rules remain fine when you have one or two trustworthy identifiers and little noise. Choose the approach that matches your data, not the one with the most advanced name.

Whichever approach a tool takes, ask:

• Who defines what a match is: you, the vendor’s model, or examples you label?
• Who designs the matching logic, and who maintains it as your data, sources and business rules change?
• If it learns from labels, how many does it need for each entity type, and who provides them?
• Can you see why two records were matched, or kept apart?
• When you correct a decision, does the correction stick on the next run?

How must it scale?

Comparing every record with every other record grows with the square of your data: a million records means about half a trillion possible pairs. So every tool narrows down which pairs it compares, a step called blocking. Some tools learn blocking or handle it for you. Others leave it to you to write blocking rules or keys, and to revisit them as data grows. Blocking that’s too loose won’t finish in time. Blocking that’s too strict silently drops true matches, because a pair that’s never compared can never be matched.

Ask:

• How are candidate pairs chosen, and who designs and maintains that logic?
• How do run time and cost change as your data grows?

How does it handle change?

Data doesn’t stand still, and tools handle new data in four quite different ways:

• Full rerun: everything is reprocessed each time. IDs can change on every run unless the tool keeps them stable.
• Append-only incremental: new records join existing entities or start new ones, but existing entities never merge or split. Updates and deletions wait for a full run.
• Full incremental: additions, updates and deletions are processed as they land, and entities merge and split as the evidence changes, with IDs kept stable.
• Real time: each record is matched as it arrives. Ask how very large loads and changes to the matching logic are handled.

Ask:

• When records are added, updated or deleted, are existing entities re-evaluated, merged or split, or are new records only attached?
• What happens on a very large load, or when the matching logic changes?
• Do IDs stay stable through all of this? Clusters merge and split as data changes, so the real question is whether downstream systems get an ID they can rely on.

Real time or batch?

Many needs are batch: monthly master data, nightly customer unification, one-off migrations. Real time matters when a decision has to happen as a record arrives, such as a fraud check at payment, KYC at onboarding or a call-centre lookup. Real-time tools usually keep their own indexed store so lookups are fast, which brings you back to where data lives. A common pattern is a batch-resolved base in your own tables, with real-time lookups served through an indexing layer such as Elastic, or real-time matching added only for the few journeys that need it. Be wary of paying for real time everywhere when only one process needs it.

Ask:

• Which decisions must happen while a record arrives, and how fast must the answer be?
• Does real-time matching use the same matching logic and the same IDs as your batch runs, or a separate model you have to keep in step?
• What does real time cost compared with running the same workload in batch?

Is it ready for agents?

Agents now both use entity resolution and run it. “Agentic entity resolution” covers three different things, so ask about each:

• Agents inside the product. Does the vendor provide agents for curation, data quality or review? Who supervises them, and where do their decisions show up?
• Operable by your own agents. Could a coding agent or AI agent you already run install the tool, configure it, and run it again whenever new data lands? Tools configured as code or structured config, run in clear steps, with no sign-up or screens to click through, are much easier for agents to operate.
• Serving agents. Do resolved entities land somewhere agents can already read, with an ID that stays the same from one run to the next? An agent reasoning over “all orders for this customer” needs to resolve the customer first, and needs the answer to be the same tomorrow.

What will it cost to own, and who supports it?

The licence is only one part of the cost. Add up everything the tool needs around it:

• building the matching and blocking logic, and maintaining it
• pipelines to copy data in and sync results back
• a second copy of sensitive data to secure, govern and audit
• separate servers, databases or clusters to run and patch
• monitoring and alerting for another system
• extra security and compliance reviews
• specialised skills: people who know a proprietary tool, rather than the platform your team already runs

A tool that runs on infrastructure you already operate, and writes results to tables you already govern, avoids most of these costs. A tool with its own compute and storage adds them.

How tools are priced. Five models are common, and each scales differently:

• By data volume (records, entities or tiers). Predictable at small scale, but cost can climb steeply as you grow. Ask for the price at your current volume and at three to five times it, and check where the tier boundaries fall.
• By API call. Common for hosted matching and real-time lookups. Cost follows how often your systems call the service, so check the price of bulk loads and full reruns.
• By resolved entity. You pay for the entities in the output rather than the records going in. Check how merges and splits change the count from one run to the next.
• By seats, projects or environments. Easy to budget, but check the limits on environments and users.
• Open source with optional commercial support or add-ons. The licence cost is zero or low; you pay in engineering time and support. Check the licence terms and what the paid tier adds.

Ask every vendor to model the three-year cost at your expected growth, including implementation and support, so the quotes are comparable.

Then ask about support and direction. Who fixes it when it breaks? Who decides what gets built next? For open-source tools, is commercial support available, and from whom?

Prove it on your data

Vendor benchmarks run on vendor data. Before you commit, test on your own:

• Accuracy. Measure precision (wrong merges) and recall (missed matches), including pairs that share no identifier.
• Wrong merges caused by bad keys. Seed a shared household email and a recycled phone number, and check that unrelated people stay apart.
• Performance. Run at your real volume, and on a larger sample that reflects the growth you expect, both for a full run and when new data lands.
• A second run. Add, update and delete records, run again, and check what happens to existing entities and IDs.
• Data preparation and time to value. Note how much cleaning, standardising and reshaping your data needs before the tool can use it, and how long it takes to get the first useful results.
• An agent setting it up. Give a coding agent the documentation and a sample of your data, and see how far it gets without help.

A one-page scorecard

Use this to compare shortlisted tools. Score each row from 0 to 3, and write down the evidence for the score.

Choose by situation

FAQ

Are entity resolution and identity resolution the same thing? Largely, yes. “Identity resolution” usually refers to people (customers, patients, citizens), while “entity resolution” is the general term that also covers companies, households, suppliers, products and locations. In advertising and customer data platforms, “identity resolution” can also mean stitching on shared identifiers such as emails and device IDs, which is a narrower technique (see “Which job do you have?”).

What’s the difference between identity stitching and identity resolution? Stitching links records that share a trusted identifier, such as an email or device ID. Resolution decides whether records are the same entity from their attributes when identifiers are missing, differ or can’t be trusted. Most organisations need both.

Is entity resolution the same as MDM? No. Entity resolution is the matching step. Master data management adds golden records, survivorship, hierarchies, stewardship and governance on top of it. How good the matching is varies a lot between MDM suites, so test it on its own.

Can I build entity resolution myself? You can, but it’s three hard problems, not one:

1. Matching. Field-level fuzzy functions and thresholds look simple. But whether two records match depends on how all their fields agree and disagree together, so hand-written rules keep needing new exceptions.
2. Scale. Comparisons grow with the square of your data, so you need blocking. Too loose and runs don’t finish; too strict and true matches are silently dropped. Either way it needs retuning as data grows.
3. Incremental change. New records bridge existing clusters, updates split them, and deletions remove the links between them. Handling merges and splits while keeping IDs stable for every downstream system is the part in-house builds most often underestimate.

See Why Entity Resolution Is Hard: 5 Problems Teams Hit and Build vs Buy Entity Resolution: The Real Engineering Cost.

How much does entity resolution software cost? It ranges from free (open source) to seven figures a year at very large volumes, and the pricing model matters as much as the price. Volume-tiered pricing climbs with data, per-call and per-entity pricing follow usage, and open source shifts the cost to engineering and support. Ask every vendor to model the three-year cost at your expected growth.

Which tools should I look at? See Top 10 Open Source Entity Resolution Tools (2026) for the open-source options, and use the scorecard above to compare any shortlist against the same questions.

Further reading

• The What and Why of Entity Resolution, the full guide to how entity resolution works
• Entity Resolution at Scale: Blocking Billions of Records
• Fellegi-Sunter Limitations and Deterministic vs Probabilistic Matching
• Incremental Identity Resolution
• Papadakis, G., Skoutas, D., Thanos, E., Palpanas, T. (2020). Blocking and Filtering Techniques for Entity Resolution: A Survey. ACM Computing Surveys 53(2).
• Peeters, R., Steiner, A., Bizer, C. (2025). Entity Matching using Large Language Models. EDBT 2025.