What's New in CData Sync 26.3

Running data pipelines at scale surfaces a specific class of problem. Not outages or obvious failures, but the quieter ones: a schema change mid-replication that populates a new column with NULLs for weeks before anyone notices. A pipeline copied six times to handle minor differences between business units, now six times as hard to maintain. A long job that finishes with an ERROR and tells you nothing about which tables made it and which did not.

CData Sync focuses on exactly this class of problem. The release expands what Sync can do across three areas that matter most to teams running production-grade pipelines: how much control you have over the process, how much visibility you have while it runs, and where data can land. Here is what shipped and why it matters.

How much control you have over the process

This is where the depth of a replication platform shows. The features in this section are built for teams managing pipelines that have grown past simple point-to-point jobs: multiple sources, evolving schemas, orchestration across dependent workflows, and source systems that behave in ways that only become apparent once they are running in production.

Pipeline variables: parameterization without the complexity

Most data integration tools that support pipeline parameterization make it harder than it needs to be. The capability is there, but it tends to live behind a proprietary expression language, a steep configuration hierarchy, or a separate orchestration layer that carries its own learning curve.

Sync 26.3 takes a more straightforward approach. Variables are defined at the pipeline level and referenced anywhere inside that pipeline using {pipeline:variablename} syntax, including inside REPLICATE queries and transformations. Read-only system attributes are also available automatically at runtime: pipeline id, name, and run start date. No additional setup, no expression builder, no separate configuration layer to learn.

The practical result is that pipelines can be parameterized and reused across environments or business units without hardcoding values into individual jobs. Teams that have been maintaining separate pipelines to handle minor variations between Dev, Test, and Production, or between regional business units with different schema names, can consolidate that work significantly.

CDC source depth: handling what production environments actually do

Change data capture works well under stable conditions. The complexity surfaces when source databases do what source databases do in real environments: schemas change mid-replication, table reorganizations happen, new columns get added to tables that are already being captured. These situations do not always announce themselves loudly. Sometimes the result is a new column silently arriving as NULL for weeks, missing rows at the destination, or duplicates accumulating after a reorganization, all without an error being thrown.

Three source-specific improvements in 26.3 address scenarios in this category.

SQL Server CDC now handles the two-capture-instance pattern that DBAs use for zero-downtime schema changes. When a schema change is applied using this pattern, a second capture instance is created before the first is dropped. Sync now detects the second instance, drains the old one, and transitions automatically. Previously, this required re-syncing the job, which could be costly if the source tables were large.

Db2 for i CDC now checks for qualifying unique indexes before falling back to RRN as the merge key. RRN, or Relative Record Number, reflects the physical position of a row in the file rather than a stored identifier. In environments where table reorganizations run frequently: a reorganization shifts row positions and reassigns RRNs, which can cause rows to appear as duplicates at the desintation or disappear as phantom deletes, with no error raised. When a stable, unique index exists, Sync now uses it instead. When one is not available, Sync falls back to RRN and logs a warning

SAP HANA CDC now regenerates triggers automatically when a schema change is detected on a source table. Previously, a column added to a HANA source table mid-replication would arrive at the destination as NULL until the task was manually recreated. Schema changes now propagate without requiring intervention.

SnapshotMode: three clear options instead of a boolean

SnapshotMode replaces the SkipSnapshot boolean with a three-way setting that applies to both standard and CDC jobs. Incremental bounds the initial snapshot using the configured check column range. Full runs a plain SELECT with no additional criteria. Skip bypasses the snapshot entirely. Each option is described in the UI directly, and the old boolean flag still works but is deprecated.

The change addresses a practical issue with SkipSnapshot: it was used to mean different things in different situations, and a single on/off toggle was not expressive enough to capture those distinctions clearly. Three named options give teams a more precise way to communicate intent, both in configuration and when reviewing job settings later.

Parallel pipeline steps

Steps in a pipeline can now run concurrently. If a pipeline includes independent jobs with separate source systems, separate destinations, and no shared state, those steps can be configured to run at the same time rather than waiting for each one to finish before the next begins. Total pipeline run time drops proportionally to the number of steps that have no dependency on each other.

Schema management at job setup

Sync no longer requires destination schemas to exist before a job can run. At job creation, you choose whether to preserve the source schema structure at the destination or consolidate everything into a single target schema. If the schema does not exist, Sync creates it at runtime. For teams managing many jobs across many schemas, this removes a setup step that was easy to overlook and harder to diagnose when missed.

How much visibility you have while it runs

A replication job that completes without errors is not the same as a replication job that completed correctly. Two changes in 26.3 make that distinction more visible during and after a run.

More precise outcomes and automatic recovery

When a task processes a large volume of data and part of it completes while the rest fails, the result used to collapse into a single ERROR regardless of how much data actually landed. That made it difficult to know whether to retry everything or treat the outcome as a transient issue and move on.

The new PARTIAL_SUCCESS status distinguishes that outcome, gives you an accurate picture of what completed and what did not, and triggers automatic retry on the failed portion if retry is configured for that task. The result is a more informative outcome that tells you what happened rather than just that something went wrong.

Live records count during a run

Tasks now display a live records-affected count that updates as data lands at the destination, without requiring a page refresh. In previous releases, a long-running task gave limited feedback while in progress. The count updates continuously, so you can see activity as it happens rather than waiting for the task to complete before understanding what ran.

Where data can land

Sync already supports a broad destination catalog spanning databases, cloud warehouses, and file systems. Two additions in 26.3 extend that further.

Kafka destination: closing the setup gap

Kafka has been a supported destination in Sync, but until 26.3 it required a Schema Registry to be in place before a connection could be configured. That requirement is now optional. Schema Registry configuration surfaces only when the message format chosen actually requires it.

Beyond that, 26.3 adds control over how data lands in Kafka. Topic routing is configurable: all tables to a single topic, one topic per table, or a naming template using {schema} and {table} variables. Partitioning is configurable too, with round-robin, primary key, or custom column expression options. Every message carries operational metadata in its Kafka headers, including source schema, source table, operation type, and commit timestamp, so downstream consumers can filter and route without parsing the message body.

New destination: Apache Doris

Apache Doris is now a supported destination in CData Sync. If your team runs Doris as an OLAP layer, you can replicate data directly to it without routing through a MySQL-compatible connection. The connector handles Doris-specific data types and SQL syntax natively.

Get the latest release

CData Sync 26.3 is available now. For full release notes, visit the CData Sync documentation portal.

Existing customers: download the latest release and generate an updated license key through the CData Portal.

Evaluating Sync for the first time: start a free trial.