TiCDC

TiCDC is an open-source change-data-capture tool that streams incremental changes from TiDB to databases, message brokers, and cloud storage. It suits teams running TiDB that need downstream feeds or cluster replication and can operate self-hosted infrastructure. Its breadth is useful, but at-least-once delivery and documented edge cases call for careful planning.

Overview

TiCDC captures TiKV change logs, orders the changes, and exports row-based data. Its log-based approach supports both an initial snapshot and ongoing replication, while schema evolution support helps keep downstream data aligned as schemas change. It can join a new TiDB deployment or be added to an existing cluster.

For recovery, TiCDC can replicate between TiDB clusters with second-level recovery point objectives and minute-level recovery time objectives. It also supports bidirectional cluster replication for multi-active deployments. Those capabilities make it relevant to TiDB operators who need continuity or active data across clusters, rather than a general-purpose replication layer detached from TiDB.

Key features

Sinks, filtering, and control

TiCDC can send changes to TiDB, MySQL-compatible databases, Kafka, Amazon S3, Google Cloud Storage, Azure Blob Storage, and NFS. Kafka users can choose among recommended Canal-JSON, Avro, and Debezium formats. This mix supports operational databases as well as feeds for monitoring, caching, indexing, and analysis, though choosing a format and downstream system remains part of the integration work.

Filtering can target databases, tables, DMLs, and DDLs. The Open API can report task status, change task configuration, and create or delete tasks, giving operators control over replication jobs without limiting the product to a fixed set of pipelines.

Availability and delivery behavior

There is no single point of failure, and TiCDC nodes can be added or removed dynamically. Production deployment guidance recommends at least two instances. The trade-off is its at-least-once delivery guarantee: a failure can cause a DDL or DML to be emitted again, including repeated Kafka messages. Downstream consumers and recovery procedures need to account for duplicates.

Constraints to plan around

TiCDC generally replicates only tables with at least one valid index; a force-replicate option covers tables without one. The docs identify RawKV-only clusters, CREATE SEQUENCE and SEQUENCE functionality, and TiDB Lightning physical imports on tables being replicated as unsupported scenarios. Large upstream transactions receive only partial support, and extremely large transactions can put the new architecture at risk of running out of memory. These constraints make it a poor fit for replication paths that depend on those cases without a workaround.

The deployment guide documents TLS between TiDB components, including TiCDC. That is a useful security control for deployments that require encrypted component traffic.

Pricing

TiCDC (open-source): free. The free, open-source offering is self-hosted, with no paid plans or usage caps stated. It fits teams prepared to deploy and operate the service themselves; the trade-off is that infrastructure and operational responsibility stay with the user.

Platforms

TiCDC is available for API, Linux, macOS, and self-hosted environments. Its deployment model is self-hosted, so teams should expect to manage its place in their TiDB cluster rather than use it as a hosted service.

Who it's for

TiCDC is best suited to TiDB teams building disaster-recovery replication, real-time feeds for monitoring or downstream analysis, or replication between heterogeneous databases. It is less suitable when a required path involves unsupported TiDB features, very large transactions, or a need for exactly-once delivery.

Pros and cons

• Pros: Multiple database, Kafka, cloud-storage, and NFS sinks let TiDB changes serve varied downstream systems.
• Pros: Filtering and task-management APIs provide control over what replicates and how jobs are managed.
• Pros: Cluster-to-cluster recovery and bidirectional replication address recovery and multi-active use cases.
• Cons: At-least-once delivery means downstream systems must tolerate duplicate statements or messages.
• Cons: Index requirements and documented unsupported scenarios can rule out particular tables or workflows.
• Cons: Extremely large transactions carry an out-of-memory risk, limiting confidence in workloads that rely on them.

Alternatives

For a broader range of replication choices, compare Data Replication Software; teams focused specifically on proxying can browse Database Proxy Software, while CDC-focused buyers can compare Change Data Capture Software.

• SymmetricDS is worth considering when its Community plan, which is free forever under AGPL v3, or its Android, iOS, web, and Windows platform coverage better suits the deployment.
• MySQL may suit readers seeking a GPL-licensed community edition with SQL and NoSQL applications plus replication and high-availability components.
• Debezium is another free, open-source distributed change-data-capture platform, and may suit teams seeking CDC across its API, Linux, and self-hosted platforms.
• Amazon Database Migration Service is a paid option with an AWS Free Tier; its stated credits are valid for up to 12 months, so consider it if that AWS offer fits your migration needs.
• Artie may fit teams that want a managed or self-hosted pipeline option with a free tier capped at 1 million billable rows per month and two active pipelines.
• Couchbase XDCR is an alternative to consider for Couchbase deployments.
• Estuary may suit teams looking for a freemium replication option with a listed $100.00 per month pay-as-you-go plan.
• Fivetran Database Replication may suit readers seeking a freemium service with a free tier that specifies monthly active-row and model-run caps.

Verdict

Choose TiCDC if you run TiDB and need self-hosted incremental replication with flexible sinks, filtering, or cluster recovery. Its strongest case is the combination of TiDB-native change capture and cluster-to-cluster options; look elsewhere if duplicate delivery, index constraints, unsupported cases, or large-transaction risk do not fit your replication path.