TiloRes vs Zentity for Entity Resolution: A Quick Comparison
TL;DR
- Choose an entity resolution platform by testing where matching happens, how current the resolved entity view is, how explanations are exposed, and how much operational ownership your team keeps.
- Zentity is documented as an Elasticsearch plugin, so it belongs in evaluations where the team already operates Elasticsearch and wants entity resolution inside that environment.
- Tilores is a fit when teams want records resolved and assembled as data is ingested, then retrieved as resolved context at query time for customer 360, fraud, support, analytics, or AI workflows.
Table of Contents
- Decision guide
- Elasticsearch limitations
- What is Zentity?
- TiloRes vs Zentity
- Scalability
- Performance & availability
- Cost
- Conclusion
- Short answer
- What should evaluators test before choosing a platform?
- How should the Tilores and Zentity comparison be framed today?
- Why does ingestion-time assembly matter?
- How should teams compare operating cost?
- Frequently Asked Questions
Decision guide
| Question | Use Tilores when | Watch-outs |
|---|---|---|
| Where should entity resolution happen? | You want records resolved and assembled as they are ingested, so applications can retrieve resolved entity context at query time. | A search-time approach can still be useful, but evaluators should test latency, candidate expansion, and how current the resolved view is under production load. |
| Does the team already operate Elasticsearch? | You do not want entity resolution tied to an existing Elasticsearch cluster, plugin lifecycle, or index design. | If comparing Zentity, verify the plugin release matches the Elasticsearch version and that the chosen hosting environment supports installable plugins. |
| How much explanation does the workflow need? | Reviewers need source-record context, match reasoning, and a resolved entity that can be used by fraud, support, analytics, or AI systems. | Any product under review should expose enough match evidence to inspect false positives and false negatives before automated decisions rely on the output. |
| How much operational ownership should the data team keep? | You want a managed resolution layer that sits next to MDM, CDP, warehouse, KYC, AML, or application systems instead of becoming another search cluster to tune. | Teams choosing an Elasticsearch-based path should budget for index design, model maintenance, cluster security, scaling tests, and version upgrades. |
The role of entity resolution is becoming increasingly critical in today’s age of “big data”. This is piling additional pressure on top of data teams that are being tasked with extracting more and more value (ad infinitum) from their complicated, bulky and, more often than not, unstructured datasets.
At the same time, these teams are arguably being somewhat held back by the limited capabilities of existing data tooling — that is, unless they can build their own, which is an unrealistic prospect for teams within the majority of firms. And by talking about tooling in the context of entity resolution, we’re of course referring to Elasticsearch.
Elasticsearch limitations
Elasticsearch is a distributed, open-source (under Apache 2.0) full-text search and analytics engine based on Apache Lucene. It is accessible via the RESTful API or the Elasticsearch Java API client and can be used to store, search, and analyse huge volumes of data and return answers in near to real-time due to its document-based structure. We recommend reading our previous blog post, Elasticsearch for entity resolution, if you want more background information on the basics of Elasticsearch.
Although the value of tools like Elasticsearch cannot be understated — it does serve a useful purpose after all, and it does this very well — it’s hard to ignore its scaling issues when it comes to entity resolution. This is unlikely to be an issue for smaller teams but once entity resolution demand grows, Elasticsearch can quickly run out of steam.
Due to this and the fact that Elasticsearch itself was not made for entity resolution, third-party tools have been built on top of it to get around its inherent limitations. One of these plugins is Zentity.
What is Zentity?
Zentity is an Elasticsearch plugin for real-time entity resolution,which operates on data that has already been indexed within Elasticsearch. It is based on Elasticsearch 100% and makes it easier for data teams to carry out entity resolution more easily and get their results faster.
Though it’s a powerful plugin, there are inherent limitations, just like with raw Elasticsearch that will be problematic for larger data teams that have more sophisticated entity resolution requirements.
That’s why we developed TiloRes, our scalable, serverless solution that eliminates many of the pain points associated with entity resolution by building up entities as data is ingested. When searches are subsequently performed, a comparison with all existing datasets is made, and any pre-built entity that the matching dataset belongs to is delivered as a search result. Since a dataset can only belong to one entity, a single search query can return multiple entities more quickly and with high accuracy.
TiloRes vs Zentity
Let’s take a quick look at how TiloRes stacks up against Zentity in terms of scalability, security, and performance.
Scalability
Scalability is arguably the most important consideration for any data team with a growth mindset in the so-called “big data” age. Datasets are inflating at a rapid pace; they are arriving in increasing volumes, contain greater variety, and are coming at us much more quickly.
This can mean that even smaller data teams may inadvertently find themselves growing at a pace they never anticipated. Scalability in tooling is therefore not so much an optional nicety as it is a necessity — and TiloRes delivers on this.
Zentity is 100% based onElasticsearch, which means that its own scalability is limited to Elasticsearch’s scalability. For single instances, entity resolution problems begin to pop up at around 1 million records. On the other hand, TiloRes’ scalability is unlimited because it’s serverless and based on demand; there is no limit to the amount of data that teams can simultaneously process. No matter if you process one request per second or ten thousand, the setup is the same and no manual intervention is needed for the system to scale. Scaling is automatic and requires no downtime or maintenance.
Performance & availability
As we mentioned earlier, Zentity’s performance will degrade as you scale because it’s based on Elasticsearch. Although it’s a fast, high-performance tool for low-volume entity resolution, most data teams will begin to experience serious performance issues which hinder their workflows at around 1 million records.
TiloRes on the other hand can scale from zero to an unlimited number of requests without any noticeable drops in performance. All components of TiloRes are always running on at least three different datacenters, which comes at no additional cost because the logic is only executed when requests are flowing in. In addition, Zentity only indexes records and must create entities during the search process whereas TiloRes matches records to entities. This means it’s possible to have different entities in a single instance and search all entities quickly. In other words, TiloRes builds the pathway to entities only once and remembers it, whereas Zentity must create the pathway each time, which is inefficient,
Cost
ElasticSearch is empirically more expensive to run than TiloRes because ElasticSearch runs on top of servers and nodes. These must always be on and cannot dynamically scale based on periods of increased demand. This leads to overprovisioned systems and a huge server requests-costs ratio, which is an issue for companies that are growing quickly because it can lead to downtime. In addition, the cost of administering and maintaining ElasticSearch is high, as experienced engineers are required for cluster setup.
With TiloRes serverless entity resolution, you only pay for what you use. During periods of low demand and low use, you’ll pay a comparatively small amount to times of peak demand and higher use. It all depends on how many requests have been made. In addition, TiloRes was built to run without the need for administration and maintenance, which eliminates costs further — it just works.
Conclusion
There’s no denying that the Elasticsearch engine coupled with Zentity is a powerful method for searching and analysing huge volumes of data in real-time. Equally, there’s no denying that with growth, Zentity’s ability to carry out entity resolution at the speed, scale, and security needed by larger data teams will begin to degrade.
At TiloTech, we help firms to overcome this challenge with our proprietary data solution, TiloRes: a serverless entity resolution technology. TiloRes offers super-fast searching, unlimited scaling, and real-time deduplication to speed up, simplify, and future-proof the entity resolution process.
Short answer
When choosing an entity resolution platform, compare the product against the shape of your data and the way downstream systems need to use resolved context. The core checks are match quality on messy records, update speed, explainability, index or ingestion requirements, security model, operational ownership, and whether the system can support both evaluation and production volume.
For this comparison, treat the original 2023 article as a dated Tilores view of Zentity and Elasticsearch-based entity resolution. A current evaluation should verify concrete criteria: Elasticsearch version compatibility, hosting support for community plugins, entity-model design effort, query-time behavior, explanation output, and the difference between resolving records at ingestion versus searching indexed records at query time.
What should evaluators test before choosing a platform?
Evaluators should start with real records that include typos, changed emails, name variants, shared phone numbers, duplicate accounts, and records that look similar but should remain separate.
The useful test is not a feature checklist alone. It is whether the platform can identify likely matches, avoid unsafe merges, explain the decision, and make the resolved context available to the systems that need it.
How should the Tilores and Zentity comparison be framed today?
The original article compares Tilores with Zentity from the perspective of a 2023 Tilores post. The safer current framing is not to repeat unsupported claims about a competitor, but to ask what each architecture requires and what each one returns.
Zentity is publicly documented as an Elasticsearch plugin for entity resolution. A current evaluator should therefore check Elasticsearch version alignment, plugin installation support, entity model setup, query profile behavior, security inheritance, and how much explanation the response exposes.
Why does ingestion-time assembly matter?
Ingestion-time assembly means incoming records are resolved into entity context before downstream applications ask for them. Query-time systems can then retrieve or use that resolved context without rebuilding the entity from scratch for every consumer.
That distinction matters for customer 360, fraud, support, analytics, and AI workflows because the same resolved context can be reused across teams instead of being reconstructed inside each search or reporting path.
How should teams compare operating cost?
Operating cost should include more than software price. Teams should include implementation time, index or ingestion design, rule and model maintenance, security review, version upgrades, monitoring, false-match review, and the cost of making resolved context available to downstream systems.
That keeps the comparison grounded in total ownership rather than broad claims. A team already committed to Elasticsearch may value a plugin path, while a team seeking a dedicated entity-resolution layer may prefer Tilores.
Frequently Asked Questions
- What features should I look for when choosing an entity resolution platform?
- Look for match quality on messy records, ingestion and update behavior, explainability, source-record traceability, security controls, scalability testing, API access to resolved context, and a clear operating model for false positives and false negatives.
- How should I compare Tilores and Zentity for entity resolution?
- Compare where matching happens, what infrastructure each option depends on, how explanations are returned, how current the resolved view is, and how much operational work your team owns. Tilores focuses on ingestion-time resolution and reusable query-time context, while Zentity is documented as an Elasticsearch plugin.
- Is Zentity still an Elasticsearch plugin?
- Yes. The current public Zentity documentation describes it as an Elasticsearch plugin for entity resolution, with plugin releases matched to Elasticsearch versions and security inherited from the Elasticsearch cluster.
- Why does query-time versus ingestion-time resolution matter?
- It changes how downstream systems consume identity context. Ingestion-time resolution assembles records before applications query them, while query-time approaches depend on the search or resolution request to retrieve matching records from indexed data.
- Should an evaluator rely on the original 2023 comparison claims?
- The original article should be treated as a dated source article. A current evaluation should preserve the original Tilores perspective while verifying present-day criteria such as plugin compatibility, hosting support, security model, explanation output, and production behavior.
Evaluate Tilores on your own data
Use the next step that matches your evaluation stage.
See what resolved entity data does for your business — and your AI.