Any source, any target, one proof.
Every connector computes the same SHA-256 based fingerprint inside its own engine, byte-verified against a reference implementation and against every other engine, so a comparison across engines is as exact as one within an engine. Where an engine cannot compute the proof in SQL, the reference path takes over and says so.
Active today.
Active means the cross-engine comparison tests are complete and byte-verified, and the connector is selectable without a badge. Readiness is published per connector in the documentation and never softened for a sale.
| System | Readiness | Notes |
|---|---|---|
| PostgreSQL 14+, Aurora PostgreSQL | Active | Native proof pushdown; bulk key extraction over server-side cursors. |
| MySQL 8.0+, Aurora MySQL | Active | Native proof pushdown. |
| Microsoft SQL Server 2019+ | Active | Native proof pushdown over UTF-8 collation; earlier versions use the reference path. |
| Oracle Database | Active | Native SHA-256 proof through DBMS_CRYPTO; a weaker fallback is flagged as advisory, never silently used. |
| IBM Db2 LUW 11.1+ | Active | Native SHA-256 proof; 10.5 and 11.0 use the reference path. |
| SAP HANA | Active | Native SHA-256 proof over UTF-8; the usual target of SAP replication. |
| Snowflake | Active | Native proof pushdown; reads pinned to the readiness instant where the table's retention allows. |
| Databricks | Active | Native proof pushdown; Delta commit versions as watermarks; collated columns handled. |
| Google BigQuery | Active | Native proof pushdown. |
| Amazon Redshift | Active | Native proof pushdown; binary content of any size through a faithful driver path. |
| ClickHouse 25.8 LTS+ | Active | Native proof pushdown; merge-resolved reads for ReplacingMergeTree and ClickPipes targets. |
| Trino (Hive, Delta Lake, Iceberg catalogs) | Active | Native proof pushdown over lake tables; reduced timestamp fidelity on some catalogs is labeled on the run. |
| File datasets: Parquet, CSV, JSON, Delta Lake, Apache Iceberg | Active | Engine-less readers on S3, ADLS, GCS and local paths, pinned to a commit or snapshot. |
| Object stores (S3, ADLS, GCS) | Active | Inventory-level: path, size and content fingerprint; file contents are the file dataset connector's job. |
| Qlik Cloud | Active | Reads the app's data through the engine; QVD files byte-exact through the file dataset connector. |
| Salesforce | Active | API read; reference path proof. |
| SAP application layer | Future release | Reconcile the physical database beneath it today (Oracle, Db2, HANA). |
| Kafka CDC | Future release | Readiness signals only; not a dataset connector. |
The authoritative list, with each connector's verification record, is in the documentation.
CDC-aware readiness.
You declare the replication tool between a source and a target; Paridity never guesses it. With a Tier-1 adapter, readiness consults the tool's own state, lag and stability before a window is fixed, so a run never compares against replication that is still in flight. Without a tool, Paridity still aligns the window from watermarks, control markers, partitions or snapshots.
| Tool | Readiness | What Paridity reads |
|---|---|---|
| Debezium | Active | Kafka Connect REST: connector state and the replicated table list. |
| Airbyte | Active | REST API: sync state and the replicated streams. |
| Fivetran | Active | REST API: connector sync completion and the replicated tables. |
| Oracle GoldenGate 21c+ | Active | Microservices REST: replicat lag and observed tables; heartbeat-table lag for classic deployments. |
| Qlik Talend Cloud Data Integration | Active | Runtime state and datasets through the REST API. |
| Direct, no CDC tool | Active | Watermarks, control markers, partitions or snapshots on the target. |
| Custom | Active | Watermark strategy set by hand, reviewed at onboarding. |
| SAP SLT, SAP BODS, Qlik Replicate, Informatica PowerExchange CDC | Future release | Adapters pending a design partner with the tool in production. Reconciliation of the tables they replicate works today without the adapter. |
SAP and other systems without a change timestamp
Many SAP tables carry no universal last-change timestamp, and a posting date is not one. Paridity never infers freshness from a business date. It uses replication metadata, SAP-native change sources, validated table-specific rules, or an explicit snapshot mode, declared per mapping and reviewed at onboarding.
Your pair not listed?
Tell us the source, the target and the tool. Early adopters bringing a new engine or replication tool get the adapter built with them.