CData Sync vs TiCDC

CData Sync replicates data from databases, SaaS applications and APIs to databases, data lakes and data warehouses. CData says it supports over 250 sources and offers a catalog of cloud and on-premises destinations. Pipelines can use incremental loading and, for supported sources, real-time Change Data Capture. ETL and ELT transformations are available through SQL or dbt Core and Cloud. Users can schedule pipelines and receive email, Slack or Teams notifications when workflows finish or fail. Sync can run on premises, in cloud environments or through CData-hosted Sync Cloud, and is listed for Linux, Windows, web, API and self-hosted use. Its APIs and scripting can manage connections and jobs, inspect status and history, download logs, and run custom behavior around jobs. It can adjust destination schemas when source schemas change; its overview says it does not delete destination columns or reduce their size. CData documents TLS/SSL encryption and encrypted sensitive configuration values and reports third-party SOC 2 Type II and ISO/IEC 27001:2022 audits. A 14-day trial is available; there is no free plan.

TiCDC is a free, open-source, self-hosted tool for replicating incremental data changes from TiDB. It captures TiKV change logs, sorts the changes, and exports row-based data to systems including TiDB, MySQL-compatible databases, Kafka, Amazon S3, GCS, Azure Blob Storage, and NFS. Recommended Kafka formats include Canal-JSON, Avro, and Debezium. Filters can select databases, tables, DMLs, and DDLs, while the Open API can check task status, change task configuration, and create or delete tasks. TiCDC supports replication between TiDB clusters for disaster recovery, with second-level RPO and minute-level RTO, as well as bidirectional replication for multi-active deployments. It can be deployed with a new cluster or added to an existing one; production guidance recommends at least two instances. The system has no single point of failure and allows nodes to be added or removed dynamically. Delivery is at least once, so failures can lead to repeated statements or Kafka messages.