Kanoniv vs Senzing

Bottom line: Senzing is a commercial entity resolution engine with proprietary "principle-based" matching that works out of the box with zero configuration. Kanoniv is a declarative platform where you define matching rules explicitly in YAML. Choose Senzing for government/intelligence use cases where you want zero-config matching with relationship discovery; choose Kanoniv for production identity resolution where you need golden records, transparent rules, and multi-tenant cloud deployment.

At a Glance

	Kanoniv	Senzing
Type	Identity resolution platform	Entity resolution engine
Approach	Declarative rules (YAML spec)	Principle-based (proprietary AI)
Source	Free SDK + Cloud	Proprietary core + OSS utilities
Deployment	Local SDK + Cloud (managed)	Self-hosted only (Docker, bare metal)
Configuration	YAML spec (explicit rules)	Zero-config (pre-built principles)
Golden Records	Yes (survivorship strategies)	No (keeps all source records intact)
Real-time API	Yes (sub-ms)	Yes (100-200ms resolution)
Multi-tenant	Yes (RLS isolation)	No
Pricing	Free tier + usage-based	Free eval (100K records), $37,440+/year production
Built by	Kanoniv	Senzing Inc. (founded by Jeff Jonas)

Feature Comparison

Feature	Kanoniv	Senzing
Deterministic matching	Yes (configurable rules)	Yes (exact identifier matching)
Fuzzy matching	Yes (Jaro-Winkler, Levenshtein, phonetic)	Yes (names, addresses, cross-script in v4)
Probabilistic matching	No	Yes (principle-based, proprietary)
Survivorship / golden records	Yes (source priority, recency, aggregation)	No (explicitly does not merge records)
Identity graph	Yes (persistent, queryable)	Yes (with relationship discovery)
Relationship discovery	No	Yes (households, networks, fraud rings)
Real-time resolution API	Yes (sub-millisecond)	Yes (100-200ms)
Batch processing	Yes	Yes
Real-time data processing	Via Cloud API	Yes (native, self-correcting)
Multi-tenant isolation	Yes (row-level security)	No
Audit logs	Yes (immutable)	Yes (explainability: why/why not/how)
HIPAA compliance	Yes (PII masking, retention)	Not documented
Cross-script matching	No	Yes (CJK + English in v4)
Training data required	No	No
Configuration required	Yes (YAML spec)	No (works out of the box)
Free engine	Yes (Rust, embedded in SDK)	No (proprietary binary)
SDK languages	Python	Python, Java, Go, C#, C++, REST, gRPC
Self-hosted option	Via Docker	Yes (primary deployment model)
Managed cloud	Yes (Kanoniv Cloud)	No
Warehouse integration	Snowflake, dbt	No (records loaded into Senzing's store)

Code Comparison

Kanoniv: Declarative rules with golden record output

# customer-spec.yaml
entity:
  name: customer
sources:
  - name: crm
    adapter: csv
    location: contacts.csv
    primary_key: id
  - name: billing
    adapter: csv
    location: stripe.csv
    primary_key: id
rules:
  - name: email_exact
    type: exact
    field: email
    weight: 1.0
  - name: name_address
    type: composite
    operator: and
    children:
      - type: jaro_winkler
        field: name
        threshold: 0.9
      - type: jaro_winkler
        field: address
        threshold: 0.85
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"),
    Source.from_csv("billing", "stripe.csv"),
]
result = reconcile(sources, spec)
print(f"Golden records: {len(result.golden_records)}")

Senzing: Zero-config, record-at-a-time processing

from senzing import G2Engine

config_json = '''{
  "PIPELINE": {
    "CONFIGPATH": "/etc/opt/senzing",
    "SUPPORTPATH": "/opt/senzing/data",
    "RESOURCEPATH": "/opt/senzing/resources"
  },
  "SQL": {
    "CONNECTION": "sqlite3://na:na@/var/opt/senzing/sqlite/G2C.db"
  }
}'''

g2 = G2Engine()
g2.init("MyApp", config_json)

# Add records -- Senzing resolves automatically
g2.addRecord("CRM", "1001", '''{
  "NAME_FULL": "Robert Smith",
  "DATE_OF_BIRTH": "1985-02-14",
  "ADDR_FULL": "123 Main St, Las Vegas NV 89101",
  "EMAIL_ADDRESS": "[email protected]"
}''')

g2.addRecord("BILLING", "B-42", '''{
  "NAME_FULL": "Bob Smith",
  "DATE_OF_BIRTH": "1985-02-14",
  "ADDR_FULL": "123 Main Street, Las Vegas NV"
}''')

# Query the resolved entity
response = bytearray()
g2.getEntityByRecordID("CRM", "1001", response)
# Returns JSON with ENTITY_ID, all resolved records, and relationships
# But no golden record -- all source records kept as-is

# Explain why two records matched
g2.whyRecords("CRM", "1001", "BILLING", "B-42", response)

When to Choose Senzing

• You need zero-configuration matching that works out of the box for people and organizations
• You're in government, intelligence, or law enforcement where Senzing has deep domain expertise (USCIS is a named customer)
• You need relationship discovery -- finding households, networks, and fraud rings, not just duplicates
• You need cross-script matching (CJK + English names and addresses)
• You want real-time streaming processing with self-correcting entity profiles
• You have budget for $37K+/year production licensing
• You need multi-language SDKs (Python, Java, Go, C#, C++, REST, gRPC)

When to Choose Kanoniv

• You need golden records with survivorship -- Senzing explicitly keeps all source records separate
• You want explicit, auditable matching rules in YAML rather than an opaque principle-based engine
• You need multi-tenant isolation for a SaaS product or multi-team deployment
• You want a managed cloud option instead of self-hosting all infrastructure
• You need warehouse-native workflows (Snowflake, dbt) -- Senzing requires loading data into its own store
• You want transparent, inspectable matching -- Kanoniv produces explainable decisions with confidence scores and rule traces; Senzing's matching engine is a proprietary binary
• You need a free production tier -- Senzing's free tier is evaluation-only (100K records, non-production)
• You want YAML-as-code identity resolution that lives in version control alongside your data pipelines

Key Differences Explained

Rules vs Principles

Kanoniv requires you to define rules. You choose which fields to compare, which algorithms to use, and what thresholds trigger a match. This gives you full control and auditability -- but you need to understand your data well enough to write good rules.

Senzing's "principle-based" approach encodes generalized knowledge about how entity attributes behave (e.g., "SSNs typically belong to one person, but birth dates are shared by many"). You don't write rules -- Senzing already knows how to resolve entities. The trade-off: less control, more magic. When it works, it's impressive. When it doesn't, debugging is harder because you can't see the principles.

Golden Records

This is the sharpest difference. Senzing does not create golden records. It keeps every source record intact and links them to a resolved entity. The philosophy is that all source data is valuable and should never be merged or discarded.

Kanoniv creates golden records with configurable survivorship strategies. You declare how to pick the "winning" value for each field -- by source priority, recency, or aggregation. The output is a single canonical record per entity, which is what most downstream systems (dashboards, CRMs, warehouses) need.

Deployment Model

Senzing is self-hosted only. You run it on your infrastructure (Docker, bare metal, or cloud VMs). There is no Senzing-managed SaaS.

Kanoniv offers both models: the Python SDK runs locally (no server required), and Kanoniv Cloud provides managed infrastructure with a persistent identity graph, real-time API, and monitoring dashboard.

Pricing

Senzing's free evaluation tier is limited to 100K records and is explicitly non-production. Production starts at $37,440/year for 10M records. This prices out many startups and smaller teams.

Kanoniv offers a free tier suitable for production use, with usage-based pricing that scales with your needs.