IBM Informix change data capture and real-time data replication

• Informix DBAs who must approve CDC on a 12.10 or 14.10 instance and want the steps in writing: the syscdcv1 database, full row logging, DB_LOCALE, and a dedicated Gluesync user
• Data platform leads feeding warehouses, lakes, and event streams from Informix, who want one Core Hub for every source and target instead of a separate tool for each
• Architects planning a move off Informix or offloading reads from it, who need the source kept in sync with the new platform until cutover, without a single big-bang switch
• Engineers who wrote their own reader on the Informix change stream and now own restarts, checkpoints, and monitoring for a pipeline the business treats as infrastructure

Native change stream through the Informix CDC API

Gluesync uses the ifx-changestream-client to capture data changes from Informix. The client provides a stream with one event per modification, and the agent connects through the built-in JDBC driver. Events are processed and replicated sequentially, so updates are applied one at a time on the target.

• Operations captured: INSERT, UPDATE, and DELETE
• Initial load: full snapshots for initial synchronization

What your DBA enables first

Capture depends on the CDC API being set up in the database. These are the documented steps.

1. Turn on full row logging with the cdc_set_fullrowlogging() function, for example EXECUTE FUNCTION cdc_set_fullrowlogging('demo:informix.articles', 1);
2. Run syscdcv1.sql as user informix from $INFORMIXDIR/etc, for example dbaccess demo $INFORMIXDIR/etc/syscdcv1.sql
3. Confirm the syscdcv1 database accepts a connection as user informix
4. Set DB_LOCALE to the locale of the database you capture from
5. Create a dedicated user for Gluesync that connects to syscdcv1 and has read access to the source tables

Connectivity, TLS, and topology

• Port: defaults to 9088
• TLS: the REST setup accepts enableTls and certificatePath

Restart-safe reader state and snapshot tuning

The source-side cache is a local ArenaCache, so a Core Hub restart or a short network outage does not force a resynchronization. The reader position is persisted in Core Hub, so an agent move or restart does not reset the reader.

Snapshot concurrency and query parallelism are configurable. Checkpoint metrics report the Informix position as InformixCdcCheckpoint.

Architecture around Core Hub

Agents sit next to your systems and capture or write data. Core Hub orchestrates pipelines, coordinates snapshots and writes, and hosts the web UI and REST API. Core Hub and agents deploy with Docker, Docker Compose, or Kubernetes.

Explore the general CDC streaming architecture →

Use the integrations directory to pair Informix as a 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.

Informix is also a write target. The target agent writes through the built-in JDBC driver, uses a staging table and a bulk SQL generator for bulk load, and honors the TRUNCATE before snapshot setting. 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 reads from Informix to another database: see database offload
• Feed a cloud warehouse or data lake continuously: see warehouse sync
• Publish Informix changes to an event-streaming platform, if the target agent you choose supports that role
• Move Informix data to a new platform with a snapshot and CDC until cutover: see cloud migration