The matching engine, ingestion pipeline and mastering path are benchmarked inside the product, in the Performance Lab. What you see below is a representative envelope measured on generated data — using the same Jaro-Winkler and Metaphone comparators and the same disjunctive blocking the live pipeline runs. No business data is touched to produce these figures.
Indicative figures from a Performance Lab run on generated data. Treat them as an envelope you can reproduce, not a guarantee — see the methodology note below.
Each stage timed independently on generated data across four volume bands. Cells are representative throughput or wall-clock, not committed service levels — they scale with your hardware and chosen hub engine.
| Pipeline stage | 100k rows | 500k rows | 1M rows | 5M rows |
|---|---|---|---|---|
| Ingest & standardize | ~8 s | ~38 s | ~1.3 min | ~6.8 min |
| Match — candidate reduction | 99.1% | 99.4% | 99.6% | 99.8% |
| Match — score & resolve | ~11 s | ~55 s | ~1.9 min | ~10 min |
| Survivorship | ~4 s | ~19 s | ~41 s | ~3.4 min |
| Publish golden | ~3 s | ~14 s | ~29 s | ~2.5 min |
| End-to-end wall-clock | ~26 s | ~2.1 min | ~4.6 min | ~23 min |
The envelope above is not a tuning trick — it falls out of how the hub is built. Four choices keep throughput high as volumes grow.
Records are grouped by multiple blocking keys before any pair is scored, so the quadratic comparison space collapses to a small candidate set. That is where the 99%+ reduction — and most of the speed — comes from.
Ingest, standardize, survive and publish run as set-based operations inside the hub database — not row-by-row in an app tier. Data stays where it lives, so there is no round-trip tax as volumes climb.
The same model and pipeline run natively on SQL Server, PostgreSQL, MySQL and Oracle. You get the throughput profile of the engine your team already tunes and operates — not a lowest-common-denominator abstraction.
Jobs distribute across cluster workers while the scheduler runs on the primary, so ingest and matching scale out by adding workers. Throughput grows with the cluster instead of hitting a single-node ceiling.
We publish an envelope, not a scoreboard. Here is exactly how these numbers are produced and what will move them on your infrastructure.
These are representative envelopes, not service-level agreements. We do not commit to any specific throughput or wall-clock as a contractual guarantee. Use the figures to understand the shape of the system and to size a starting point, then reproduce your own numbers in the Performance Lab against data that looks like yours. Contractual performance commitments, where offered, are set out separately in the applicable agreement.
We'll run the Performance Lab against a sample shaped like your sources and walk you through the envelope — matching, mastering and publish, end to end.