Real-time data replication to YugabyteDB from your operational databases

• Architects planning a move from PostgreSQL or Oracle to distributed SQL who want YugabyteDB populated and current before cutover, rather than loaded once in a long freeze window
• Data platform leads who want one Core Hub for every source feeding YugabyteDB, backed by best-in-class enterprise support, rated 4.9/5 by customers
• Application teams running PostgreSQL-compatible services on YugabyteDB who need it kept in sync with another system in both directions, with recursion protection so writes never loop
• Engineers replacing a Debezium pipeline, a scheduled ELT job, or a custom sync script with one product for every source, with snapshots, checkpoints, and monitoring built in

The write path: the YugabyteDB smart JDBC driver

The YugabyteDB agent connects through the YugabyteDB smart JDBC driver, which knows the cluster topology and routes each connection to a live node. It is a target agent: it receives changes from any Gluesync source agent and writes them to your tables as SQL.

• Load balancing: the Load balance option spreads connections across the nodes of the cluster, and the driver fails over when a node goes away.
• Security: the connection supports TLS, configured with a certificate path.
• Ports: the agent connects to the YSQL port, 5433 by default.
• YugabyteDB agent overview ↗

Optimized batches, never row by row

Gluesync never writes one row at a time to YugabyteDB. Incoming changes are grouped into chunks and applied as SQL batch operations, so each round-trip to the cluster carries many rows and the smart driver spreads that work across nodes. Batch size is configurable on the target agent, separately for writes and for deletes, so you can push throughput during an initial load and keep transactions short once the cluster serves production traffic.

Snapshot first, then continuous CDC

• Seed, then stream: snapshot jobs seed each table in YugabyteDB, then the entity follows the source change stream continuously.
• INSERT or UPSERT: INSERT with TRUNCATE before snapshot, which the YugabyteDB agent honors, is the fast path for empty or reset tables; UPSERT merges the snapshot with rows already in the cluster.
• Target-side SQL: the agent runs your own SQL before and after each snapshot and before and after CDC starts, for example to adjust session settings or indexes around a large load.
• Resume: an interrupted snapshot resumes from its last saved state when you start the entity again.
• Bidirectional pipelines: Enable Recursion Protection filters out the changes made by the agent's own connection username, so a pipeline that runs in both directions does not feed its own writes back to the source.

Duplicate keys and table creation

• On duplicate key: Upsert is the default, and it overwrites the row already in YugabyteDB with the incoming one. Skip keeps the existing row, writes the rest of the transaction, and raises a warning in Notifications Hub that lists the skipped keys. Fail stops the entity so someone can resolve the conflict. See on duplicate key ↗.
• Table creation: when a target table does not exist, Core Hub's table creation wizard generates the CREATE TABLE statement from the source columns, types, and primary key, and you review it before it runs.
• Gluesync schema: the agent keeps its own metadata in a dedicated schema, created automatically unless you turn automatic schema creation off.

What your YugabyteDB admin sets up

The agent needs a user with read and write access to the target tables and database. The YugabyteDB target setup guide ↗ lists every field.

1. Create or choose a user with read and write permission on the target database and its tables.
2. Note the host or IP address, the port (5433 by default), and the database name.
3. In Core Hub, add the YugabyteDB target agent with the username and password, and turn on Load balance when the cluster has several nodes to spread connections across.
4. Attach the agent to a pipeline with one or more source agents, choose the duplicate-key behavior per entity, and switch on recursion protection for pipelines that also read from the same cluster.

Architecture around Core Hub

Source agents sit close to each database, the YugabyteDB agent sits close to the cluster, and Core Hub coordinates them through its web UI and REST API. Every component deploys with Docker, Docker Compose, or Kubernetes, on-premises or in any cloud. See cloud migration for how the same pipelines keep a target current until cutover.

Explore the general CDC streaming architecture →

Any Gluesync source agent can feed YugabyteDB, each with its own native capture technique. Open the integrations finder with YugabyteDB pre-selected to see every source you can pair with it, including PostgreSQL-compatible sources for a straightforward move.

Several sources can feed one YugabyteDB cluster through one Core Hub, each pipeline with its own snapshot, duplicate-key behavior, and monitoring. Gluesync keeps pace with your change volume at any scale, and batch sizes and load balancing are configurable on the agent.

• PostgreSQL to YugabyteDB from the write-ahead log: see PostgreSQL CDC
• Oracle to YugabyteDB from the redo logs through LogMiner or XStream: see Oracle CDC
• MySQL to YugabyteDB from the binlog: see MySQL CDC
• MongoDB to YugabyteDB from Change Streams: see MongoDB CDC