Kanoniv vs Zingg

Bottom line: Zingg is an ML-based entity resolution tool that runs on Spark and learns matching rules from labeled examples via active learning. Kanoniv is a declarative platform where you define matching rules explicitly in YAML. Choose Zingg when you have complex, messy data where you'd rather label examples than write rules; choose Kanoniv when you want deterministic, auditable matching with golden records and a real-time API.

At a Glance

	Kanoniv	Zingg
Type	Identity resolution platform	ML-based entity resolution
Approach	Declarative rules (YAML spec)	Active learning + ML
Language	Python SDK (Rust engine)	Java/Scala (Python API available)
License	Free SDK + Cloud	AGPL v3 (Community), Commercial (Enterprise)
Runtime	Local PyO3 engine + Cloud API	Apache Spark
Configuration	YAML file	Active learning labeling + JSON config
Golden Records	Yes (survivorship strategies)	Enterprise only (Zingg IDs)
Real-time API	Yes (sub-ms)	No
Multi-tenant	Yes (RLS isolation)	No
Built by	Kanoniv	Zingg.AI

Feature Comparison

Feature	Kanoniv	Zingg Community	Zingg Enterprise
Deterministic matching	Yes	No	Yes
Fuzzy matching	Yes	Yes (ML-based)	Yes (ML-based)
Probabilistic/ML matching	Yes (Fellegi-Sunter with EM)	Yes (active learning)	Yes
Survivorship / golden records	Yes	No	Yes (Zingg IDs)
Identity graph	Yes (persistent)	No	Knowledge graph
Real-time resolution API	Yes	No	No
Incremental matching	Yes	No	Yes
Batch reconciliation	Yes	Yes	Yes
Multi-tenant isolation	Yes (RLS)	No	No
Audit logs	Yes (immutable)	No	No
HIPAA compliance	Yes	No	Not documented
Multi-language support	No	Yes (CJK, Hindi, Thai)	Yes
Spark required	No	Yes	Yes
Training data required	No	Yes (active learning labels)	Yes
Warehouse integration	Snowflake, dbt	Databricks, Snowflake (Snowpark)	Databricks, Snowflake, Fabric

Code Comparison

Kanoniv: Declarative YAML spec

# customer-spec.yaml
entity:
  name: customer
sources:
  - name: crm
    adapter: csv
    location: contacts.csv
    primary_key: id
rules:
  - name: email_exact
    type: exact
    field: email
    weight: 1.0
  - name: name_fuzzy
    type: jaro_winkler
    field: name
    threshold: 0.9
    weight: 0.8
survivorship:
  strategy: source_priority
  priority: [crm, billing]
decision:
  thresholds:
    match: 0.85

from kanoniv import Spec, Source, reconcile, validate

spec = Spec.from_file("customer-spec.yaml")
validate(spec).raise_on_error()

sources = [Source.from_csv("crm", "contacts.csv")]
result = reconcile(sources, spec)
print(f"Golden records: {len(result.golden_records)}")

Zingg: Active learning workflow

from zingg.client import Arguments, ClientOptions, ZinggWithSpark
from zingg.pipes import CsvPipe

# Define input pipe
input_pipe = CsvPipe("customers", "contacts.csv")

# Define field types
args = Arguments()
args.setFieldDefinition([
    {"fieldName": "name", "matchType": "FUZZY"},
    {"fieldName": "email", "matchType": "EMAIL"},
    {"fieldName": "phone", "matchType": "FUZZY"},
    {"fieldName": "address", "matchType": "FUZZY"},
])
args.setData(input_pipe)
args.setOutput(CsvPipe("output", "/tmp/zingg_output/"))
args.setModelId("customer_model")
args.setZinggDir("/tmp/zingg_models/")

# Step 1: Generate training pairs
options = ClientOptions([ClientOptions.PHASE, "findTrainingData"])
zingg = ZinggWithSpark(args, options)
zingg.initAndExecute()

# Step 2: Label training pairs (interactive)
options = ClientOptions([ClientOptions.PHASE, "label"])
zingg = ZinggWithSpark(args, options)
zingg.initAndExecute()

# Step 3: Train the ML model
options = ClientOptions([ClientOptions.PHASE, "train"])
zingg = ZinggWithSpark(args, options)
zingg.initAndExecute()

# Step 4: Match records
options = ClientOptions([ClientOptions.PHASE, "match"])
zingg = ZinggWithSpark(args, options)
zingg.initAndExecute()
# Output includes z_cluster, z_minScore, z_maxScore columns

When to Choose Zingg

• Your data is too messy for hand-written rules and you'd rather label examples than define thresholds
• You're running on Spark/Databricks and want a Spark-native solution
• You need multi-language support (CJK, Hindi, Thai, etc.)
• You're doing large-scale batch matching on a Spark cluster (100M+ records)
• You want ML-based matching that improves with labeled examples
• You need Zingg Enterprise features: incremental matching, persistent Zingg IDs, golden records, knowledge graph

When to Choose Kanoniv

• You want deterministic, explainable rules rather than ML-based matching
• You need golden records with survivorship out of the box (not just Enterprise)
• You need a real-time resolution API for application integration
• You want no Spark dependency -- Kanoniv runs locally with no infrastructure
• You need multi-tenant isolation for a SaaS deployment
• You want audit logs and compliance features (HIPAA, GDPR)
• You prefer YAML configuration over an active learning labeling workflow
• You want to validate locally during development before deploying to production

Key Differences Explained

ML vs Rules + Probabilistic

Zingg's strength is that it learns matching logic from labeled examples. You label 30-50 pairs as "match" or "not match," and the ML model generalizes to the full dataset. This works well when rules are hard to articulate -- e.g., matching product names with inconsistent formatting across suppliers.

Kanoniv supports both declarative rules and Fellegi-Sunter probabilistic matching with EM training. You can define explicit rules for deterministic cases and use probabilistic scoring for fuzzy cases -- all in the same spec. Every match decision is traceable to a specific rule with a reason code, and AutoTune can optimize thresholds automatically.

Spark Dependency

Zingg requires Apache Spark. Even for small datasets, you need a Spark runtime (local mode, Databricks, EMR). This adds operational complexity but enables scale to billions of records.

Kanoniv's core engine is embedded in the Python SDK via PyO3. You can reconcile on a laptop with pip install kanoniv -- no Spark, no servers, no infrastructure. For production scale, Kanoniv Cloud handles the heavy lifting.

Free Tier Scope

Zingg Community (AGPL) includes the core ML matching engine but lacks golden record creation, incremental matching, and deterministic matching -- those are Enterprise-only features.

Kanoniv's free SDK includes validation, planning, diffing, and local reconciliation with full survivorship. The split is local vs cloud, not basic vs advanced matching features.