SOLUTION · YUGABYTEDB CDC

YugabyteDB change data capture and real-time data replication

Real-time YugabyteDB CDC from logical replication slots, without polling tables or running a Kafka Connect cluster.

Gluesync by MOLO17 captures committed changes from YugabyteDB with a dedicated source agent. The agent reads PostgreSQL-compatible logical replication over replication slots and connects through the YugabyteDB JDBC smart driver. Changes are delivered continuously to the databases, warehouses, lakes, and event streams your teams already run, and every pipeline is managed from Core Hub, the Gluesync control plane.

Start a Gluesync trial Talk to us

WHO THIS IS FOR

YugabyteDB teams that need changes out of a distributed SQL cluster

YugabyteDB DBAs who must approve a replication user without SUPERUSER, with a documented list of the replication privilege, the schema grants, and the replica identity each captured table needs
Data platform leads feeding Snowflake, BigQuery, data lakes, Kafka, or other databases from YugabyteDB, who want one control plane for sources and targets instead of a Kafka Connect mesh
Engineers who prototyped a Debezium connector or a polling script and now own Kafka Connect clusters, connector restarts, and on-call for a pipeline the business treats as infrastructure
Teams replacing a homegrown sync job or a second replication product with one agent-based pipeline, including bidirectional setups where YugabyteDB is both source and target

THE PROBLEM

YugabyteDB data that only moves in batches goes stale, and the cluster pays for every extract

Analytics and downstream applications that read YugabyteDB through scheduled extracts or timestamp polls work from a copy that is already behind. On a distributed SQL cluster, every poll is more work for the nodes that serve production traffic. Buyers searching for YugabyteDB CDC or real-time YugabyteDB to Kafka usually compare three options: a Debezium connector that they run on Kafka Connect, a polling job their own team maintains, or a second replication product that adds a license and another system to operate.

Gluesync addresses that with per-agent CDC. A YugabyteDB source agent reads committed changes from a logical replication slot, target agents write to the destinations you choose, and Core Hub connects the two.

HOW IT WORKS

How Gluesync does YugabyteDB CDC

Logical replication over replication slots

The YugabyteDB agent consumes changes through YugabyteDB's built-in PostgreSQL-compatible logical replication. This replication is enabled by default in YugabyteDB. The agent connects with the YugabyteDB JDBC smart driver, which provides cluster awareness, load balancing, node failover, and TLS support.

Offsets are tracked in Core Hub metadata together with replication slot positions.
Committed changes are streamed in near real time. TRUNCATE events are read and forwarded to targets.
User-defined data types are supported.
Snapshot jobs seed the YugabyteDB tables before CDC resumes, and snapshot query parallelism is configurable.

What your DBA will be asked to enable

The agent needs a role with replication privileges and permission to read tables, schemas, and replication slots. The example below uses these statements. Adapt the user name, password, and schema list to your estate.

CREATE USER gluesync WITH REPLICATION LOGIN PASSWORD '<password>'; creates the replication user. The agent does not require SUPERUSER.
GRANT USAGE ON SCHEMA public TO gluesync; and GRANT SELECT ON ALL TABLES IN SCHEMA public TO gluesync; give read access to the example schema. Repeat the grants for every other schema you capture.
Set REPLICA IDENTITY FULL on each captured table when you need before and after images. The prerequisites also accept REPLICA IDENTITY DEFAULT.

Connections, topology, and TLS

Connection fields are hostname or IP address, port (5433 by default), database name, username, and password. The REST API takes the same host credentials, with enableTls and certificatePath for TLS.
Load balance is off by default. When it is on, the smart driver spreads connections across the cluster.
Additional hosts passes a list of hosts in the form host1:port1,host2:port2 to the driver at bootstrap.
Topology keys pass placement keys to the driver in the form cloud1.datacenter1.rack1:1.

Architecture around Core Hub

Lightweight agents sit close to each system; Core Hub hosts the web UI and REST APIs and routes changes between source and target agents. A pipeline groups the YugabyteDB source agent, its target agents, and the entities they replicate. Core Hub and agents deploy with Docker, Docker Compose, or Kubernetes.

Explore the general CDC streaming architecture →

CAPTURE OPTIONS

The YugabyteDB source agent

One source agent covers YugabyteDB, so the decision is whether your cluster exposes PostgreSQL-compatible logical replication to a dedicated role, not which agent to pick.

Agent	Capture technique	Versions	Best for
YugabyteDB agent ↗	PostgreSQL-compatible logical replication over replication slots, read through the YugabyteDB JDBC smart driver	YugabyteDB 2.0 and later; YSQL, the PostgreSQL-compatible API	YugabyteDB clusters where a dedicated replication user can hold the replication privilege and the captured tables can use the replica identity setting. Pair it with a YugabyteDB target or any other Gluesync target.

TARGETS AND TOPOLOGIES

Use YugabyteDB as a source, a target, or both

Use the integrations directory to pair YugabyteDB as source or target with relational engines, NoSQL stores, cloud warehouses, object and lake storage, or event streams, subject to each agent's documented source and target role. The target role writes through the YugabyteDB JDBC smart driver with topology-aware routing and TLS.

YugabyteDB can also receive changes. The target agent supports the Core Hub insert conflict strategies and the TRUNCATE before snapshot option. Its recursion protection setting filters changes made by the agent's own connection username, which is how loops are avoided in bidirectional setups. Gluesync keeps pace with your change volume at any scale. MOLO17 Professional Services can size the deployment with your team.

Target agents write in optimized batches, never row by row, and switch to native bulk load for both snapshots and CDC on targets such as Snowflake, Google BigQuery, Amazon Redshift, Microsoft SQL Server, and PostgreSQL.

Offload reporting and API reads from YugabyteDB to PostgreSQL, SQL Server, or a NoSQL store: see database offload
Feed Snowflake, BigQuery, or a data lake continuously with destination-native bulk loading: see warehouse sync
Publish YugabyteDB changes to Apache Kafka or another event-streaming platform for microservices and integration
Run a snapshot plus CDC to keep YugabyteDB and a cloud target aligned until cutover: see cloud migration

FAIR, HIGH-LEVEL COMPARISON

Where Gluesync fits among YugabyteDB CDC approaches

Approach	What buyers usually get	Where Gluesync fits
YugabyteDB's Debezium-based connector	An open-source capture pattern built around Kafka. You run Kafka, Kafka Connect, offsets, connector restarts, and upgrades yourself	Agent-based capture with Core Hub operations and best-in-class MOLO17 enterprise support (rated 4.9/5 by customers), delivering to targets beyond Kafka without a Kafka mesh; read the Debezium alternative comparison
xCluster replication	Cluster-to-cluster replication native to YugabyteDB, most often chosen when the destination is another YugabyteDB cluster	Gluesync delivers YugabyteDB changes to non-YugabyteDB targets under one Core Hub, and the target agent also writes into YugabyteDB
Qlik Replicate / Fivetran HVR-class commercial CDC	Broad commercial portfolios with mature enterprise tooling. YugabyteDB coverage and packaging differ by product, so check each vendor's current list	Agent-based commercial CDC with the YugabyteDB JDBC smart driver and one Core Hub for every source and target; see migrating to Gluesync for supported paths
Cloud-managed CDC services	Convenient inside one cloud. The supported sources and targets follow that provider's list	Agents run with Docker, Docker Compose, or Kubernetes close to your YugabyteDB clusters, and targets are not limited to one provider
DIY scripts and timestamp polling	Full control with high build and operations cost. Polling adds load to the nodes that serve production traffic	A productized agent with snapshots, slot-based offsets tracked in Core Hub, and Core Hub operations; see CDC streaming

YugabyteDB CDC research and implementation detail

What is YugabyteDB CDC with Gluesync?

Change data capture from YugabyteDB by reading committed changes through PostgreSQL-compatible logical replication over replication slots. The source agent connects with the YugabyteDB JDBC smart driver, and Gluesync agents and Core Hub deliver the changes to configured targets.

What does the DBA have to enable on the database?

A role with the replication privilege, read access to the captured tables, schemas, and replication slots, and a replica identity of FULL or DEFAULT on each captured table. Use FULL where before images are needed. The agent does not require SUPERUSER.

Does Gluesync work with a multi-node cluster and node failures?

Yes. The JDBC smart driver provides cluster awareness, load balancing, and node failover, and you can pass additional hosts and topology keys to it at bootstrap.

Can Gluesync write to YugabyteDB, not only read from it?

Yes. The target agent writes through the YugabyteDB JDBC smart driver with TLS support, applies the Core Hub insert conflict strategies, and offers recursion protection for bidirectional pipelines.

Does a snapshot run before CDC starts?

Yes. Snapshot jobs seed the YugabyteDB tables before CDC resumes, and snapshot query parallelism is configurable.

Where should we start?

Follow the YugabyteDB source setup and target setup guides, then start a Gluesync trial against a non-production copy of your cluster. Talk to MOLO17 if you need help with the replication privileges or sizing.

CDC BY SOURCE DATABASE

Other sources Gluesync captures from

Evaluate Gluesync against your YugabyteDB logical replication stream

Start a trial on your infrastructure, or talk to MOLO17 about the right setup for your cluster, replication privileges, and targets.

Start a Gluesync trial Talk to MOLO17