Declarative Identity Resolution vs Traditional MDM
Published February 2026 · 10 min read
Traditional MDM platforms — Informatica, IBM InfoSphere, SAP MDG — were built for a world where data lived in on-premise databases, changes were infrequent, and a dedicated MDM team managed the "master." That world is gone.
Modern data teams operate in a different reality:
- Hundreds of SaaS applications per organization, each generating customer data
- Data warehouses (Snowflake, BigQuery, Databricks) as the center of gravity
- Data engineers who think in code, not GUIs
- CI/CD pipelines for everything, including data transformations
- Speed: New data sources get added monthly, not annually
Traditional MDM doesn't fit this world. The implementation takes 12-24 months. The license costs $500K-$2M. The platform is a monolith that doesn't integrate with the modern data stack. And the matching engine — the most important component — is often the weakest part.
This post argues that declarative identity resolution (the Kanoniv approach) is a better fit for modern data teams than traditional MDM.
What Traditional MDM Looks Like
A typical MDM implementation:
- Vendor selection (3-6 months): Evaluate Informatica, IBM, SAP, Reltio
- Implementation (6-18 months): Configure the platform, build integrations, migrate data
- Data stewardship (ongoing): Dedicated team reviews exceptions, approves merges
- Maintenance (ongoing): Upgrade cycles, vendor support, custom development
The platform provides:
- Matching engine (often basic deterministic rules)
- Stewardship UI (web app for reviewing matches)
- Golden record store (proprietary database)
- Data governance (workflows, approvals, access control)
- Data distribution (sync golden records to consuming systems)
The Problems
It's slow. 12-24 months to first value. By the time you're live, the business requirements have changed.
It's expensive. $500K-$2M in licensing, plus $200K-$500K in implementation services, plus $100K-$200K/year in maintenance. Total first-year cost: $800K-$2.7M.
It's a black box. The matching engine is proprietary. You can't inspect the algorithm, you can't version-control the rules, and you can't run it locally. When a match is wrong, debugging requires the vendor's support team.
It's a monolith. The platform handles matching, governance, distribution, and stewardship in one system. If the matching engine is good but the governance UI is bad, too bad — you bought the whole platform.
It doesn't integrate with the modern stack. Traditional MDM platforms pre-date Snowflake, dbt, Airflow, and the modern data stack. Integration requires custom ETL, often through proprietary connectors.
What Declarative Identity Resolution Looks Like
The declarative approach: define your matching logic in a version-controlled spec, run it locally or in the cloud, and compose it with best-of-breed tools for everything else.
# customer-spec.yaml — your entire matching logic in one file
entity:
name: customer
sources:
- name: salesforce
adapter: warehouse
query: "SELECT * FROM raw.salesforce.contacts"
primary_key: sf_id
- name: stripe
adapter: warehouse
query: "SELECT * FROM raw.stripe.customers"
primary_key: cus_id
rules:
- name: email_exact
type: exact
field: email
weight: 1.0
- name: name_phone
type: composite
children:
- type: jaro_winkler
field: name
threshold: 0.9
- type: exact
field: phone
survivorship:
strategy: source_priority
priority: [salesforce, stripe]
decision:
thresholds:
match: 0.85
review: 0.65from kanoniv import Spec, Source, reconcile, validate
spec = Spec.from_file("customer-spec.yaml")
validate(spec).raise_on_error()
sources = [
Source.from_warehouse("salesforce", conn, "SELECT * FROM raw.salesforce.contacts"),
Source.from_warehouse("stripe", conn, "SELECT * FROM raw.stripe.customers"),
]
result = reconcile(sources, spec)
golden_df = result.to_dataframe()
golden_df.to_sql("golden_customers", warehouse_conn, if_exists="replace")What You Get
| Capability | How |
|---|---|
| Matching engine | Kanoniv SDK (Rust, runs locally) |
| Golden records | Built into reconcile() output |
| Version control | YAML spec in git |
| Local development | pip install kanoniv, run on laptop |
| CI/CD | Validate spec in GitHub Actions |
| Data warehouse | Write golden records to Snowflake/BigQuery |
| Data quality | dbt tests, Great Expectations |
| Orchestration | Airflow, Prefect, Dagster |
| Governance | Atlan, DataHub (if needed) |
What You Don't Get (and May Not Need)
| Capability | Traditional MDM | Declarative |
|---|---|---|
| Stewardship UI | Built-in | Build with Retool, or use Kanoniv Cloud dashboard |
| Data distribution | Built-in connectors | Write to warehouse, use reverse ETL (Census, Hightouch) |
| Reference data management | Built-in | Separate tool or custom tables |
| Hierarchy management | Built-in | Kanoniv Cloud or custom |
The Comparison
| Dimension | Traditional MDM | Declarative (Kanoniv) |
|---|---|---|
| Time to first value | 12-24 months | Days to weeks |
| First-year cost | $800K-$2.7M | Free (local) to $10K (cloud) |
| Matching logic | GUI configuration, proprietary | YAML spec, version-controlled, free SDK |
| Local development | Not possible | Full offline reconciliation |
| CI/CD integration | Limited | Native (spec validation in pipeline) |
| Warehouse integration | Custom ETL | Native (reads from, writes to warehouse) |
| Explainability | Vendor-dependent | Full — inspect the spec, inspect the code |
| Vendor lock-in | High | None (MIT license, YAML is portable) |
| Matching engine quality | Often basic | Rust engine, Jaro-Winkler, Levenshtein, phonetic, composite |
| Scale | Enterprise-grade | 100K+ local, unlimited cloud |
| Team required | Dedicated MDM team | Data engineers (existing team) |
When Traditional MDM Still Makes Sense
To be fair, traditional MDM platforms have capabilities that declarative tools don't replicate:
Multi-domain master data. If you need to manage customers, products, vendors, locations, and reference data in a single governed platform, MDM is designed for this. Kanoniv is focused on identity resolution (customers, patients, leads) — not product or vendor master data.
Stewardship at scale. If you have a team of 10+ data stewards processing thousands of exceptions per day with complex approval workflows, a purpose-built stewardship UI matters. Building this in Retool or a custom app is possible but requires engineering effort.
Regulatory mandate. Some industries (pharmaceuticals, financial services) have regulatory requirements that specifically mention MDM. A platform with built-in compliance certifications can simplify regulatory conversations.
You already have one. If you've already invested $1M+ in an MDM platform and it's working, the switching cost may not be justified. But for net-new initiatives, starting with declarative identity resolution is almost always the right choice.
The Migration Path
If you're on a traditional MDM platform and want to move to a declarative approach:
Phase 1: Shadow Mode (2-4 weeks)
Run Kanoniv alongside your existing MDM. Feed it the same sources. Compare the golden records.
# Compare Kanoniv results with existing MDM
mdm_golden = pd.read_sql("SELECT * FROM mdm.golden_customers", conn)
kanoniv_golden = result.to_dataframe()
# How many entities does each find?
print(f"MDM entities: {len(mdm_golden)}")
print(f"Kanoniv entities: {len(kanoniv_golden)}")
# Where do they disagree?
# (Join on a common identifier and compare)Phase 2: Parallel Run (1-2 months)
Both systems produce golden records. Downstream consumers use the MDM output. A dedicated engineer monitors differences and tunes the Kanoniv spec until results converge.
Phase 3: Cutover
Switch downstream consumers to Kanoniv golden records. Keep the MDM platform in read-only mode for a month as a safety net. Then decommission.
Phase 4: Decompose
Replace remaining MDM capabilities with composable tools:
- Data quality: dbt tests, Great Expectations
- Data governance: Atlan, DataHub
- Data distribution: Census, Hightouch (reverse ETL)
- Orchestration: Airflow, Prefect
The Bottom Line
Traditional MDM was the right answer in 2010. In 2026, the modern data stack has better options for each individual capability. Identity resolution — the core of MDM — is best served by a declarative, version-controlled, locally testable tool that integrates with your existing warehouse and orchestration layer.
The declarative approach gives you:
- 10x faster time to value (days vs months)
- 10-100x lower cost (free to $10K vs $800K+)
- Full transparency (inspect the spec, not a vendor's black box)
- No lock-in (MIT license, YAML is portable, data stays in your warehouse)
- CI/CD integration (validate matching rules in your deployment pipeline)
Start with identity resolution. Add governance if and when you need it. Don't buy a monolith for a matching problem.