Skip to content

Customer Deployment Overview

Short Version

Paridity is deployed as a customer-owned application inside the customer's cloud or private platform. The customer keeps their existing data systems, identity provider, secret manager, and replication tools. Paridity adds the control plane and execution workers that prove replicated datasets are complete and correct.

In the Phase 1 deployment model, Paridity does not operate customer production infrastructure. Credentials, object names, schema names, run history, and evidence stay inside the customer's environment.

What the Customer Already Has

Most customers already have these systems before Paridity is introduced:

Area Customer-owned examples
Source systems SAP ECC/S4, Oracle, DB2 LUW, SQL Server, PostgreSQL, MySQL, SAP HANA
Target systems Snowflake, Databricks, BigQuery, Redshift, Trino/Hive, cloud object stores
Replication tools SAP SLT, Qlik Replicate, GoldenGate, Debezium, Airbyte, Fivetran, Informatica CDC
Identity provider Okta, Microsoft Entra ID, Keycloak, Cognito, generic OIDC/SAML
Secret manager AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, Vault, Infisical
Cloud platform AWS, Azure, GCP, OpenShift, private Kubernetes, or another container platform

Paridity integrates with those systems. It does not replace them.

What Paridity Deploys

Paridity's core application stack contains:

Component Purpose
React UI Browser interface for operators, analysts, admins, and auditors
FastAPI API Authenticated control plane API for configuration, runs, evidence, and audit
PostgreSQL Paridity metadata, run lifecycle, audit, and append-only evidence store
Temporal Durable workflow engine for long-running reconciliation jobs
Scheduler worker Starts scheduled reconciliation work
Readiness worker Checks CDC/watermark readiness before a run starts
SQL worker Connects to source and target systems and performs proof/key extraction work
Diff worker Runs targeted row and field-level diffs using DuckDB/Arrow
Evidence worker Writes immutable proof, diff, audit, lag retry, and metric records
Notification worker Sends operational and audit notifications
Connectors Runtime adapters for source and target data systems
Replication adapters Runtime adapters for declared replication tools and CDC state

Temporal is an internal Paridity runtime dependency. Customers do not need to write Temporal workflows or expose Temporal to business users, but in the customer-deployed model their platform/SRE team must operate the Temporal service unless a separate managed-service agreement says otherwise.

Logical Architecture

Customer users
    |
    v
Customer IdP  ---->  Paridity UI
                         |
                         v
                    Paridity API
                         |
          +--------------+--------------+
          |                             |
          v                             v
  Paridity PostgreSQL              Temporal
   cfg / run / ev / proj               |
                                       v
                          Paridity worker pods
                            |       |       |
                            v       v       v
                       Sources  Targets  Replication tools
                            |
                            v
                    Customer secret manager

Deployment Packaging

The standard production packaging is:

Artifact Purpose
Backend container image Runs the API and all workers; the container command selects the role
Frontend container image Serves the React UI
Helm chart Installs the full Paridity stack into Kubernetes
Terraform references Provision cloud infrastructure such as Kubernetes, managed Postgres, networking, and secret references
Migration job Applies Paridity database migrations on install or upgrade
Preflight job Verifies the customer's secret backend configuration before rollout

Kubernetes is the recommended production deployment target because it gives a portable operating model across AWS, Azure, GCP, OpenShift, and private cloud. Other deployment models are possible, but they require more customer-specific packaging and runbooks.

What Paridity Stores

Paridity's own PostgreSQL has four logical schemas:

Schema Contents
cfg Configuration, identity records, grants, schedules, policies, audit
run Execution requests, run lifecycle, watermarks, attempts, CDC state
ev Append-only proof results, mismatch keys, field diffs, metrics, evidence bundles
proj Derived projections (run summaries, metric rollups, baselines) - recomputable from ev.*, rewritten in place, never an audit source

Paridity stores secret references, not credentials. A connection_ref points to the customer's secret manager, where the actual credential lives.

What Does Not Leave the Customer Environment

In the customer-deployed model, these stay inside the customer boundary:

  • Source and target credentials
  • Object, schema, table, and column names
  • Resolved configuration snapshots
  • Watermarks and CDC state
  • Proof results and row-level mismatch evidence
  • Field-level diff evidence
  • Audit history

Typical Production Shape

For a medium enterprise deployment:

  • Kubernetes cluster: EKS, AKS, GKE, OpenShift, or private Kubernetes
  • Managed PostgreSQL with backups and point-in-time recovery
  • External or dedicated Temporal persistence
  • Multiple API replicas
  • Scaled SQL and diff worker pools
  • Customer IdP integration
  • Customer secret manager integration through workload identity
  • Ingress with TLS
  • Network egress restricted to approved customer systems
  • Logs and audit events integrated with the customer's monitoring/SIEM tooling