Google Cloud Datastream vs TiCDC

Google Cloud Datastream is a serverless change data capture and replication service for synchronizing data. Streams can capture ongoing updates and backfill historical records, while the service scales automatically without resources for users to provision or manage. Supported destinations include BigQuery, Cloud Storage, and Apache Iceberg tables. Documented sources include Oracle, MySQL, PostgreSQL, AlloyDB, SQL Server, MongoDB, Spanner, Salesforce, ServiceNow, Workday, and Microsoft Dataverse; some sources are marked as preview. Datastream can work with Dataflow templates to load data from Cloud Storage into destinations including BigQuery, Cloud SQL, and Spanner. Connectivity options include IP allowlisting, a forward SSH tunnel, and private connectivity over VPC peering. Processing is charged, idle streams incur no cost, and other Google Cloud resources are billed separately. The free tier includes 100 GiB of eligible CDC data per month per billing account. Events are delivered at least once, but ordering is not guaranteed. Datastream is administered through the Google Cloud console, CLI, or REST API.

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.