CatDB Research
Menu

Architecture

Semantic definitions stay separate from physical execution

CatDB treats schemas and mappings as versioned inputs to planning. Federation and materialization are choices made after the mapping is validated.

Source-to-domain integration

Four source schemas, one canonical commerce schema

A retailer keeps customer records, orders, fulfillment links, and product search data in different systems. Four typed mappings connect those physical schemas to one domain.

Physical source schemasEach system keeps its native shape
Typed mappingsSource fields acquire domain meaning
Canonical schemaOne model for queries and integration
01

PostgreSQL

Customer records

crm_customers(
  customer_uuid, full_name, email
)
  • customer_uuid → Customer.id
  • full_name → Customer.name
maps to Customer
02

MongoDB

Online orders

orders { orderNo, custRef,
  lines: [{ sku, qty }] }
  • orderNo → Order.number
  • lines[] → LineItem
maps to Order + LineItem
03

Neo4j

Fulfillment graph

(Order {order_no})
-[:CONTAINS {qty}]->(Product {sku})
  • order_no → Order.number
  • CONTAINS → LineItem.product
maps to Order + Product
04

Vector index

Catalog search

{ product_id, embedding,
  metadata: { sku, title } }
  • product_id → Product.id
  • metadata.sku → Product.sku
maps to Product
Commerce v1

Shared typed domain

CustomerOrderLineItemProduct
Customer.id
UUID
Order.number
Text
LineItem.qty
Integer
Product.sku
Text
Canonical query pathCustomer.orders.items.product
The mappings meet at the canonical schema. They do not require the source databases to adopt the same tables, documents, graph edges, or indexes.

What the mapping layer records

  1. Types and paths. Each source field maps to a typed domain field or relationship.
  2. Identity. Source keys remain traceable while CatDB records how they refer to canonical entities.
  3. Execution choices. A planner can federate the sources or materialize a view without moving the domain meaning into a separate pipeline.

Six layers

  1. Physical source schemas
  2. Typed categorical schema presentations
  3. Validated schema mappings
  4. Composed semantic integration plans
  5. Federated or materialized execution
  6. Versioned semantic workspaces

Reusable mapping shape

Si→FiD→GjTjS_i \xrightarrow{F_i} D \xrightarrow{G_j} T_j

A source maps into a shared domain. A consumer maps out of that domain. The conditional reuse argument depends on those mappings being adequate, maintained, and explicit about information loss.

Executable semantic core

The finite schema, mapping, instance, loss, and schema-diff semantics are expressed in Rust and Haskell against one shared fixture set. Lean checks a selected group of path and mapping laws.