SOLUTION · REPLICATE TO INFORMIX

Real-time data replication to Informix 12.10 and 14.10

Committed changes from your systems of record land in Informix continuously, through JDBC batches and staging-table bulk loads, instead of waiting for the next export and load job.

Gluesync by MOLO17 captures changes from Oracle, SQL Server, PostgreSQL, Db2, IBM i, MongoDB, and other heterogeneous sources with a dedicated agent per database. The Informix target agent writes them into Informix through the JDBC driver bundled with Gluesync, in large SQL batches or through a staging table with a native bulk apply. 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

WHO THIS IS FOR

Teams that keep Informix current with the systems around it

Informix DBAs and reporting engineers who need tables that track the source as changes happen, with control over the write path and what happens when a key already exists
Data platform leads who keep Informix in step with Oracle, SQL Server, PostgreSQL, or Db2 and want one Core Hub for every source, backed by best-in-class enterprise support, rated 4.9/5 by customers
Architects who run a long-lived Informix system alongside newer platforms, and need the Informix copy aligned with the source for as long as both stay in service
Engineers replacing a hand-built change reader, a Kafka JDBC sink, or scheduled export and load scripts, who want every source delivered to Informix by one product, with snapshots and monitoring built in

THE PROBLEM

Informix data that arrives in batches is already behind

Informix systems that receive data from other platforms are usually fed by scheduled extracts. A job queries the source on a timer, lands the rows, and loads them with a utility or a script, so the applications on Informix 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 Informix ingestion or an Informix CDC pipeline usually weigh the engine's own replication features, commercial replication products, Debezium with a Kafka sink, or code they write and keep running themselves.

Gluesync addresses that with per-agent CDC into Informix. A source agent reads each database's native change mechanism, Core Hub routes the changes, and the Informix target agent writes them through JDBC, with staging-table bulk loads for large snapshots and busy tables. Oracle to Informix, Db2 to Informix, or SQL Server to Informix all share the same pipeline model, the same snapshots, and the same operations.

HOW IT WORKS

How Gluesync writes to Informix

The write path: JDBC with bulk staging

The Informix agent connects through the JDBC driver that Gluesync bundles. It is a target agent: it receives changes from any Gluesync source agent and writes them to your tables.

Optimized batches, never row by row

Gluesync never writes one row at a time to Informix. Incoming changes are grouped into chunks and applied as SQL batch operations, which cuts network round-trips and keeps the load on the server predictable. The chunk size is configurable on the target agent. Batch mode is the default write path and the steady choice for continuous CDC.

Native bulk load for snapshots and CDC

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 written to a staging table in the Gluesync schema on the target, and a bulk SQL generator applies it to the final table with Informix's native set-based statements.

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 in one pass, and the staging table is cleared for the next cycle.

Snapshot first, then continuous CDC

Seed, then stream: each entity loads its full table into Informix, then switches to CDC from its source agent's change mechanism.
INSERT or UPSERT: INSERT with TRUNCATE before snapshot, which the Informix agent honors, is the fast path for empty or reset tables; UPSERT merges the snapshot with rows already in Informix.
Target-side SQL: the agent runs your own SQL before and after each snapshot and before and after CDC starts, for example to adjust constraints or refresh statistics around a reload.
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. See schedules and events.

Duplicate keys and identifiers

When an incoming row carries a key that already exists in the Informix table, the On duplicate key setting decides what happens, and you set it per entity. Upsert is the default and overwrites the existing row with the incoming one. 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.

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

What your Informix DBA sets up

The agent needs a user that can read and write the target tables. The connection fields and the TLS options are in the Informix target setup guide ↗. Core Hub and agents deploy with Docker, Docker Compose, or Kubernetes, next to each database or in any cloud.

Create a user with read and write access to the target tables in the Informix database you write to.
Keep a schema for Gluesync's staging tables, which the agent creates for you unless automatic schema creation is turned off.
In Core Hub, enter the host or IP address, the port (9088 by default), the database name, and the credentials.
Turn on TLS for the connection and set the certificate path in the connection settings.

Explore the general CDC streaming architecture →

WRITE OPTIONS

The Informix target agent: one agent, two write paths

Informix has one Gluesync target agent. The write path is chosen per entity: optimized JDBC batches for steady CDC, or staged bulk load for snapshots and busy tables.

Agent	Write technique	Versions	Best for
Informix agent ↗	Bundled JDBC driver; optimized SQL batches, staging table with a native bulk apply per entity	Informix 12.10 and 14.10	Informix targets that stay current with Oracle, SQL Server, PostgreSQL, Db2, or MongoDB. Keep batch mode for steady CDC, and switch on bulk load for the snapshot and for CDC on large or busy tables.

SOURCES AND TOPOLOGIES

Feed Informix from the systems of record you already run

Any Gluesync source agent can feed an Informix target, each with its own native capture technique. Open the integrations finder with Informix pre-selected to see every pairing you can build.

One Core Hub runs several sources into one Informix server 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 tune batch sizes, bulk settings, and locking with your DBA.

Oracle to Informix from the redo logs through LogMiner or XStream: see Oracle CDC
Db2 for LUW to Informix from the transaction log or triggers: see Db2 LUW CDC
IBM i (AS/400) to Informix through the native journal APIs: see IBM i CDC
PostgreSQL to Informix from the WAL, and SQL Server to Informix through Change Data Capture or Change Tracking: see PostgreSQL CDC and SQL Server CDC

FAIR, HIGH-LEVEL COMPARISON

Where Gluesync fits among Informix ingestion approaches

Approach	What buyers usually get	Where Gluesync fits
Native Informix replication features	Built into Informix for topologies between Informix servers; sources outside Informix need another tool	One pipeline model from Oracle, SQL Server, PostgreSQL, Db2, IBM i, or MongoDB into Informix, with Core Hub operations across all of them
Commercial replication products	Commercial CDC suites with broad source and target lists; coverage, packaging, and supported Informix versions differ by product	Native capture per engine and an Informix write path with staged bulk load under one Core Hub; see migrating to Gluesync
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 Informix tables with no Kafka cluster in the path, and Kafka stays available as another target. Read the Debezium alternative comparison
Scheduled export and load scripts	Full control, with your team owning extract queries, load utilities, 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	Agents run on-premises or in any cloud, so Informix stays aligned with sources wherever they live; see cloud migration

Informix replication research and implementation detail

What does replicating to Informix with Gluesync involve?

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

Which Informix versions can Gluesync write to?

Informix 12.10 and 14.10, through the JDBC driver bundled with Gluesync.

How does Gluesync write to Informix?

In optimized SQL batches through the bundled JDBC driver, with the batch size configurable on the target agent. Entities that need more throughput switch to staged bulk load.

Does Gluesync bulk load into Informix?

Yes, for the initial snapshot and for ongoing CDC, each switched on per entity. Core Hub collapses each cycle's changes by primary key, writes them to a staging table, and applies deletes and inserts to the final table in one pass.

Which sources can replicate to Informix?

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

What happens when a row already exists in Informix?

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.

What does the Informix DBA need to set up?

A user with read and write access to the target tables and a schema for staging tables, which the agent creates by default. The agent connects to port 9088 by default, and TLS can be turned on for the connection.

REPLICATE TO A TARGET