Cetus vs TiCDC
Cetus
github.comTiCDC
docs.pingcap.comSide by side
| Figure | Cetus | TiCDC |
|---|---|---|
| Price from | — | Free |
| Free plan | — | Yes |
| Free trial | — | — |
| Open source | — | Yes |
| macOS | — | Yes |
| Linux | Yes | Yes |
| API | — | Yes |
| Self-hosted | Yes | Yes |
| Plans published | 0 | 1 |
| Spec score · Database Proxy Software | 7.3 (#22) | 8.1 (#6) |
| Deployment | Cetus runs only on Linux, and its installation guide describes compiling and installing it from source. | TiCDC can be deployed with a new TiDB cluster or added to an existing cluster using TiUP. |
| Purpose | Cetus is C middleware that acts as a MySQL database access proxy, allowing applications to connect through it for database-layer horizontal scaling and high availability. | TiCDC replicates incremental data from TiDB by capturing TiKV change logs, sorting the changes, and exporting row-based data to downstream systems. |
| Security | The repository lists security management and client-side SSL/TLS support as features, while its usage constraints page says TLS is unsupported; the pages therefore give conflicting TLS information. | The deployment guide documents enabling TLS between TiDB components, including TiCDC. |
| Support | The repository directs users to open an issue for bugs or feature requests and asks them to search existing issues first. | PingCAP directs paid-plan users to support tickets and all users to community Slack support. |
Plans
In their own words
TiCDC
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.