The October 2025 release of Data Ingestion and Replication includes the following new features and enhancements.
Common
The October 2025 release of Data Ingestion and Replication includes the following new features that are common to multiple types of ingestion and replication tasks.
CLAIRE Copilot summaries of ingestion and replication tasks
CLAIRE Copilot for Data Integration can now generate brief and detailed summaries of database ingestion and replication tasks and application ingestion and replication tasks to help you understand how they're configured. To summarize a task, the task must be saved and valid. To produce the summary of a task, enter "Summarize ths asset" or "Generate detailed summary." For more information, see the CLAIRE Copilot for Data Integration documentation.
Performance-related custom properties added in the task configuration wizard
In the latest task configuration wizard, the Custom Properties section of the Task Details source and target pages now includes some commonly used custom properties that can help improve performance for your convenience. These specific properties vary by source or target type and load type. When you configure an application or database ingestion and replication task, you can easily set one or more of these properties. The Custom option is also still available if you need to manually enter any custom property that a technical support representative has provided for your unique requirement. For more information, see the Application Ingestion and Replication and Database Ingestion and Replication documentation.
Inline help panel added in the latest task configuration wizard
The new task configuration wizard for application and database ingestion and replication tasks now includes an inline help panel on the right side of each page for ease of access to help information about the page. To display the inline help, use the small arrow icons (<, >) on the right border.
Databricks unmanaged target tables supported for volume staging
Application ingestion and replication tasks and database ingestion and replication tasks that have Databricks targets can now use Databricks unmanaged tables for volume staging.
To stage data in volumes, in the Databricks connection properties, set Staging Environment to Volume.
To use unmanaged tables, select the Create Unmanaged Tables check box on the target step of the task details. For volume staging, you must also provide the complete path to a parent directory that exists in Amazon S3 or Microsoft Azure Data Lake Storage to hold the files that are generated for each target table when captured DML records are processed.
Deletion of volumes generated for volume staging in Databricks targets
For application ingestion and replication tasks and database ingestion and replication tasks that have a Databricks target and use volumes as the staging environment, if you do not provide a path to the files within a volume in the Volume Path field of the connection properties, a new volume is generated automatically. The volume is deleted when an initial load job is successfully completed and when a job of any load type is stopped at any time. Only a volume that is empty is automatically deleted. The volume is not deleted when the initial load phase of a combined load job is completed.
Improved rule validation for column selection rules
For sources in application or database ingestion and replication tasks where you can select or deselect columns from the source tables to replicate data, primary key columns remain selected by default and you cannot manually deselect them. While you can add rules to exclude columns, you can now run a validation to check these rules. The validation warns you if your rule excludes a primary key column.
Less caching of information for data lake targets
The amount of information that application or database ingestion and replication jobs cache during data replication to data lake targets has been reduced to improve performance. Data lake targets include Amazon S3, Google Cloud Storage, Microsoft Azure Data Lake Storage, Microsoft Azure Data Lake Storage Gen2, Microsoft Fabric OneLake, and Oracle Cloud Object Storage.
New CLI commands to override schema drift settings when resuming jobs
The Data Ingestion and Replication CLI now includes commands to override the schema drift settings configured in the user interface when resuming jobs that are in a Stopped, Aborted, or Failed state because of schema drift errors in incremental load and combined load application or database ingestion and replication jobs. These overrides apply only to tables in an Error state caused by the Stop Table or Stop Job schema drift options.
Use the following CLI commands to override the schema drift settings when resuming a job:
•job resumeWithOptions ignore <job name>. Does not replicate DDL changes from the source to the target.
•job resumeWithOptions stopTable <job name>. Stops processing the source object affected by the DDL change.
•job resumeWithOptions replicate <job name>. Applies the DDL changes to the target and resumes the job.
The resumed job uses the specified schema drift override to process the schema change that caused the job to stop. Afterward, the schema drift options originally configured when creating the task take effect again.
New Scheduled filter in Operational Insights
In Operational Insights, you can now use the Scheduled filter to filter and view scheduled application or database ingestion and replication initial load jobs. This filter is available on both the Overview and All Jobs pages to help you easily check the schedule details and job status of the jobs.
Enhancements for specifying Data Directory and Schema Directory expressions for data lake targets
You now have the option to edit the expressions for the Data Directory and Schema Directory fields when configuring an application or database ingestion and replication task that has a data lake target such as Amazon S3, Google Cloud Storage, Microsoft Azure Data Lake Storage, Microsoft Azure Data Lake Storage Gen2, Microsoft Fabric OneLake, and Oracle Cloud Object Storage.
Instead of typing directory expressions manually and searching documentation for supported syntax, you can directly edit these fields to modify the directory paths. You can select and insert supported variables and functions to create directory and schema paths.
Path pattern elements such as folder path, timestamp, schema name, and table name are available, along with a list of variables and functions to help you build your Data Directory or Schema Directory expressions.
Validation checks ensure your expression is valid, helping prevent errors before you save the expression.
Apache Iceberg Open Table format available to write to Amazon S3
You can use application or database ingestion and replication tasks to replicate data to Amazon S3 cloud storage as Apache Iceberg tables. You can then access these tables directly from Amazon S3 using the AWS Glue Catalog.
Snowflake Superpipe SDK and JDBC driver updates
The Snowflake Superpipe SDK version has been upgraded to 4.1 and the Snowflake JDBC driver version has been upgraded to 3.25.0. These updates apply to both database ingestion and replication tasks and application ingestion and replication tasks.
Database Ingestion and Replication
The October 2025 release of Database Ingestion and Replication includes the following new features and enhancements:
Db2 for LUW Log-based CDC
Database ingestion and replication incremental load and combined load tasks that have a Db2 11.x for LUW source can now capture change data from the database logs. The Db2 source must be on a Linux or Windows system.
This new feature is available only to organizations for which Informatica has enabled the feature. To request access, contact Informatica Global Customer Support.
When you configure a task in the latest configuration wizard, select Log-based in the CDC Method field and set the associated Catalog Table Name, Capture Threading, and Log Read Buffer Size fields.
Before you use this CDC method, complete the following prerequisites:
•Ensure that archive logging is active for the Db2 source database from which change data will be captured.
•Define Db2 source tables with the DATA CAPTURE CHANGES clause. If you use the deprecated LONG VARCHAR or LONG VARGRAPHIC data types, define the tables with the DATA CAPTURE CHANGES INCLUDE LONGVAR COLUMNS clause. The CDC script that is generated when you configure a task includes SQL statements for setting this option on each source table.
•Ensure that a valid Db2 environment exists for the Database Ingestion and Replication user. On Linux, the path to the Db2 client must be specified in the PATH and LD_LIBRARY_PATH environment variables.
Tasks that use this CDC method can process source tables that use row compression and can be included in a staging group.
This CDC method does not support the following items: sources on AIX systems, Db2 pureScale environments, LOB and XML data types, and user-defined DISTINCT and STRUCT data types.
For more information, see the Database Ingestion and Replication documentation.
MongoDB sources in combined initial and incremental load tasks
Database Ingestion and Replication now supports MongoDB sources in combined initial and incremental load tasks that have any supported target type. For more information, see the Database Ingestion and Replication documentation.
SAP HANA sources in combined initial and incremental load tasks
Database Ingestion and Replication now supports SAP HANA log-based and trigger-based CDC sources in combined initial and incremental load tasks that have any supported target type. The following limitations apply:
•Job-level resynchronization of combined load jobs with SAP HANA trigger-based CDC sources is not supported. Table-level resynchronization continues to be supported.
•For table-level synchronization of SAP HANA trigger-based CDC sources, the default option is Resync (refresh). This option drops the table and re-creates the source schema at the point of resynchronization. However, after the resynchronization, if an Add Column schema drift change occurs, data for the newly added column isn't captured.
Custom data type mapping for PostgreSQL sources and Oracle targets
You can now define rules to customize mappings of PostgreSQL source and Oracle target data types to override the default mappings described in the "Default Data Type Mappings" help.
To use custom data type mappings, add a mapping rule on the target details page when creating the task.
Custom data type mapping rules are applied only during deployment and schema drift. When the target table is created, custom data type mappings will not be evaluated at runtime while loading data to the target table, with the exception of schema drift handling.