SOLUTION · REPLICATE TO DB2

Real-time data replication to Db2 for LUW and Db2 for IBM i

Committed changes from your systems of record land in Db2 continuously, as JDBC batches on LUW and staged bulk loads on IBM i, instead of waiting for the next export and load job.

Gluesync by MOLO17 captures changes from Oracle, SQL Server, PostgreSQL, MySQL, Informix, MongoDB, and other heterogeneous sources with a dedicated agent per database. A Db2 target agent then writes them into Db2 for LUW through the JDBC driver bundled with Gluesync, or into Db2 for IBM i through the IBM JTOpen JDBC driver over TLS-secured channels. Each table is seeded by a snapshot, CDC follows, and Core Hub, the Gluesync control plane, runs every pipeline from one web UI and REST API.

Start a Gluesync trial Talk to us

VENDOR COMPATIBILITY

Battle-tested on every IBM Db2 you deliver to

The same Gluesync IBM Db2 agent is tested against each vendor offering below, self-managed or fully managed, so delivery behaves the same wherever IBM Db2 runs.

IBM Db2 for LUW Source Target Tested
IBM Db2 for IBM i (AS/400) Source Target Tested

WHO THIS IS FOR

Teams that need Db2 to reflect operations now, not after the nightly load

Db2 DBAs and reporting engineers who keep Db2 schemas current with tables keyed like the source, a per-entity rule for keys that already exist, and SQL hooks that run on the target before and after each snapshot
Data platform leads who keep Db2 for LUW or Db2 for IBM i in step with Oracle, SQL Server, PostgreSQL, or MongoDB and want one Core Hub for every source, backed by best-in-class enterprise support, rated 4.9/5 by customers
IBM i modernization architects who place Db2 as an operational copy, a reporting replica, or a migration target, and need the copy aligned with the source right up to cutover
Engineers replacing Debezium with a Kafka JDBC sink, or nightly export and load scripts, who want every source delivered to Db2 by one product, with snapshots, checkpoints, and monitoring built in

THE PROBLEM

Db2 data that arrives in batches is already behind

Most Db2 estates that receive data from other systems are fed by scheduled extracts. A job queries the source on a timer, lands the rows, and loads them into Db2 tables, so reports and RPG or Java applications run on the state of the business at the last load. Every extract adds read load to a production system, and each source ends up with its own connector, schedule, and failure mode. Teams looking for real-time Db2 ingestion or a Db2 CDC pipeline usually weigh IBM's own replication suite, Debezium with a Kafka JDBC sink, commercial replication products, or scripts they keep running themselves.

Gluesync addresses that with per-agent CDC into Db2. A source agent reads each database's native change mechanism, Core Hub routes the changes, and a Db2 target agent writes them through the JDBC path for its platform. Oracle to Db2 for LUW, IBM i to Db2 for LUW, or MongoDB to Db2 for IBM i all run on the same pipeline model, the same snapshots, and the same operations.

HOW IT WORKS

How Gluesync writes to Db2

The write path: JDBC into Db2 for LUW and Db2 for IBM i

The Db2 for LUW agents connect through the JDBC driver bundled with Gluesync, a type 4 pure Java driver over TCP/IP, and write changes straight into your tables. The Db2 for IBM i agent uses the IBM JTOpen JDBC driver, also bundled, over TLS-secured channels. All of them are target agents: they receive changes from any Gluesync source agent, and a pipeline groups the source agent, the Db2 agent, and the entities they replicate.

Db2 for LUW: one JDBC write path for both Db2 for LUW agents, with configurable character encoding.
Db2 for IBM i: JDBC batches for steady CDC, plus staged bulk load for large snapshots and high-change tables, chosen per entity.

Optimized batches, never row by row

Gluesync never writes one row at a time to Db2. Incoming changes are grouped into chunks and applied as SQL batch operations, which cuts network round-trips and keeps the load on the Db2 server predictable. The chunk size is configurable on the target agent, separately for writes and deletes, so you can favor throughput on a well-provisioned server or shorter transactions on a busy one. Batch mode is the default on both platforms and the steady path for continuous CDC.

Native bulk load for snapshots and CDC on Db2 for IBM i

On Db2 for IBM i, bulk mode is switched on per entity with two independent settings, one for the initial load and one for ongoing changes. During each mirroring cycle Core Hub collects the change events and collapses them by primary key: an insert followed by a delete is skipped, and consecutive updates become one update. The combined set is exported to CSV files and ingested with fast COPY statements into a staging table in the Gluesync staging schema.

Columns the source log omitted can be filled from the live table before the apply. Deletes for the changed keys run first, then inserts and the remaining updates are applied from staging in one pass, and the staging table is cleared for the next cycle. Each changed key lands as one current row, and the IBM i server runs a few set-based statements per cycle instead of one per change.

Snapshot first, then continuous CDC

Seed, then stream: each entity loads its full table into Db2, then switches to CDC from its source agent's change mechanism.
INSERT or UPSERT: INSERT with TRUNCATE before snapshot is the fast path for empty or reset tables, and both Db2 target agents honor the truncate option; UPSERT merges the snapshot with rows already in Db2.
Parallel loads: snapshot writing concurrency is configurable per entity, and logical partitioning splits large source tables into ranges read in parallel.
Resume: an interrupted snapshot resumes from its last saved state when you start the entity again.
Scheduled refreshes: the Chronos Scheduler runs snapshots on a cadence for tables you prefer to reload, for example off-hours. See schedules and events.

Duplicate keys, target-side SQL, and identifiers

When an incoming row carries a key that already exists in the Db2 table, the On duplicate key setting decides what happens, per entity, on both Db2 platforms. Upsert is the default and overwrites the existing row. Skip keeps the row already on the target, writes the rest of the transaction, and raises a warning in Notifications Hub that lists the skipped keys. Fail stops the entity on that transaction so someone can resolve the conflict first.

On Db2 for LUW, the agent runs your own SQL at four points: before and after each snapshot, and before and after CDC starts. Teams use these hooks to set session parameters, suspend and restore constraints around a reload, or refresh statistics once a large load completes.

Db2 for IBM i folds unquoted identifiers to upper case, so Core Hub normalizes target column names and filter clauses to UPPERCASE when an entity is saved, and the CREATE TABLE statements it generates for new tables follow the same case.

What your Db2 administrator sets up

Each platform needs a user that can read and write the target tables. Full connection fields are in the Db2 for LUW target setup guide ↗ and the Db2 for IBM i target setup guide ↗. Core Hub and agents deploy with Docker, Docker Compose, or Kubernetes, next to each database or in any cloud.

Db2 for LUW: create a user with read and write access to the target database and tables. In Core Hub, enter the host, the port (50000 by default), the database name, the credentials, and the character encoding.
Db2 for IBM i: create a user with read and write access to the target tables. In Core Hub, enter the host, the database name, and the credentials.
Db2 for IBM i network: open port 449 for IBM i service discovery, then the TLS service ports for the database and its companion services (9470, 9471, 9475, and 9476) from the agent host.

Explore the general CDC streaming architecture →

WRITE OPTIONS

The Db2 target agents: one agent per Db2 platform

Db2 for LUW and Db2 for IBM i each have a Gluesync target agent, and Db2 for LUW offers two. All of them write in optimized JDBC batches; the Db2 for IBM i agent adds staged bulk load per entity for snapshots and CDC.

Agent	Write technique	Versions	Best for
IBM Db2 for LUW agent ↗	Bundled JDBC driver (type 4); optimized SQL batches written straight to the Db2 tables	Db2 for LUW 11.5 and later, Community Edition included	Db2 for LUW reporting replicas, offload targets, and consolidation projects, fed from any Gluesync source agent with configurable batch sizes and pre and post SQL hooks.
IBM Db2 for LUW CDC agent ↗	Bundled JDBC driver; optimized SQL batches written straight to the Db2 tables	Db2 for LUW 11.5 and later, single-instance and partitioned environments	Db2 for LUW estates that also capture changes with the log-based Db2 for LUW source agent, so one agent type serves both directions in the same Core Hub.
Db2 for IBM i agent ↗	IBM JTOpen JDBC driver over TLS; SQL batches by default, staged CSV and COPY bulk load per entity	IBM i 7.1 and later	Db2 for IBM i targets such as a reporting copy or a new IBM i instance. Keep batch mode for steady CDC, and switch on bulk load for the snapshot and for CDC on large or busy tables fed from Oracle, SQL Server, PostgreSQL, or MongoDB.

SOURCES AND TOPOLOGIES

Feed Db2 from the systems of record you already run

Any Gluesync source agent can feed a Db2 target, each with its own native capture technique. Open the integrations finder with Db2 pre-selected to see every pairing, from Oracle and SQL Server to Informix, SAP HANA, and MongoDB.

One Core Hub runs several sources into one Db2 platform side by side, with the same snapshot, monitoring, and duplicate-key policy for each entity. Gluesync keeps pace with your change volume at any scale, and you choose the write path per table. MOLO17 Professional Services can plan the topology and the cutover with your team.

Oracle to Db2 for LUW from the redo logs through LogMiner or XStream: see Oracle CDC
SQL Server to Db2 for LUW through Change Data Capture or Change Tracking: see SQL Server CDC
IBM i (AS/400) to Db2 for LUW through the native journal APIs, a common step in IBM i modernization: see IBM i CDC
Informix to Db2 for LUW, and PostgreSQL or MongoDB to Db2 for IBM i: see Informix CDC, PostgreSQL CDC, and MongoDB CDC

FAIR, HIGH-LEVEL COMPARISON

Where Gluesync fits among Db2 ingestion approaches

Approach	What buyers usually get	Where Gluesync fits
IBM InfoSphere Data Replication	IBM's own replication suite, usually chosen where the estate is already IBM-centric and the team runs that suite day to day	Agents you deploy next to each source, Oracle, SQL Server, MongoDB, or IBM i alike, with one Core Hub for every pipeline; see CDC streaming
Fivetran HVR, Qlik Replicate, and similar commercial replication	Commercial log-based replication with broad target lists; coverage, packaging, and supported versions differ by product	Native capture per engine and Db2 write paths, including staged bulk load into IBM i, under one Core Hub. For IBM i specifically, read Gluesync vs Fivetran HVR for IBM i
Debezium with Kafka Connect and a JDBC sink	Open-source capture into Kafka topics, then a sink connector writes rows into the database; your team runs Kafka, Connect, offsets, and schema handling	Changes applied to Db2 tables with no Kafka cluster in the path, and Kafka stays available as another target. Read the Debezium alternative comparison
Native Db2 replication between Db2 databases	Built into Db2 for keeping Db2 databases in step with each other; sources outside Db2 need another tool	One pipeline model from any Gluesync source into Db2 for LUW or Db2 for IBM i, with Core Hub operations across both platforms
Scheduled ELT and export scripts	Full control, with your team owning extract queries, load jobs, retries, and the load each run puts on production	Log-based capture, snapshot resume, and continuous apply, with Core Hub monitoring instead of job code to maintain; read batch ETL vs real-time replication
Cloud-managed migration services	Managed inside one cloud, with source and target options that follow that provider's catalog	Core Hub keeps Db2 aligned with sources that stay where they are until cutover, and agents run on-premises or in any cloud; see cloud migration

Db2 replication research and implementation detail

What does replicating to Db2 with Gluesync involve?

A source agent captures committed changes from your database through its native change mechanism, Core Hub routes them, and a Db2 target agent applies them to Db2 tables continuously after a snapshot seeds each table.

Which Db2 versions can Gluesync write to?

Db2 for LUW 11.5 and later, including Community Edition, in single-instance and partitioned environments, and Db2 for IBM i 7.1 and later.

How does Gluesync write to Db2 for LUW?

Through the type 4 JDBC driver bundled with Gluesync, in optimized SQL batches whose size is configurable on the target agent. Changes are written straight into the target tables.

Does Gluesync bulk load into Db2 for IBM i?

Yes, for the initial snapshot and for ongoing CDC, switched on per entity. Core Hub collapses each cycle's changes by primary key, ingests them into a staging table with CSV files and fast COPY statements, then applies deletes and inserts in one pass.

Which sources can replicate to Db2?

Any Gluesync source agent, including Oracle, SQL Server, PostgreSQL, MySQL, MongoDB, Informix, and IBM i. The integrations finder on our website lists every pairing.

What happens when a row already exists on the Db2 target?

The On duplicate key setting, chosen per entity, decides. Upsert, the default, overwrites the existing row; Skip keeps it and raises a warning that lists the skipped keys; Fail stops the entity on that transaction.

Can Core Hub truncate Db2 tables before a snapshot?

Yes. INSERT snapshots truncate the target table first by default, both Db2 target agents honor the option, and an agent-level setting turns truncation off for every entity that writes through it.

What does the Db2 administrator need to set up?

A user with read and write access to the target tables and database. Db2 for LUW listens on port 50000 by default. Db2 for IBM i connects over TLS, so port 449 and the TLS service ports 9470, 9471, 9475, and 9476 must be reachable from the agent.

REPLICATE TO A TARGET