PgDog vs TiCDC

PgDog is a PostgreSQL connection pooler, load balancer, and database sharder designed to scale databases without application changes. It multiplexes many application connections across fewer PostgreSQL server connections and supports SET, LISTEN/NOTIFY, and advisory locks. Read queries can be distributed across replicas while writes go to the primary, with health checks and failover detection. Sharding keys guide query routing; queries without a key can run across databases in parallel. Cross-shard transactions use PostgreSQL prepared transactions and two-phase commit, with automatic rollback on errors. PgDog can copy data and stream row changes to another database without pausing query traffic. Deployment options include Kubernetes Helm, Docker, AWS ECS Terraform, pre-built binaries, and source. Releases include Linux arm64 and amd64, Apple Silicon Mac, and Debian packages; the macOS binary is unsigned. The project is free and open source under AGPL-3.0, and documentation says internal use does not require sharing source code. Enterprise support includes architecture reviews, a dedicated Slack channel, and an SLA promising a response within 15 minutes.

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.