The October 2025 release of Data Ingestion and Replication includes the following new features and enhancements.
Watch the What's New video to learn about the new features and enhancements in the October 2025 release.
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.
Serverless runtime environments
Data Ingestion and Replication extends support for serverless runtime environments hosted on Microsoft Azure. You can run the following types of application ingestion and replication jobs and database ingestion and replication jobs on a serverless runtime environment:
Application ingestion and replication sources:
•For all load types:
- Marketo
- Microsoft Dynamics 365
- NetSuite
- Oracle Fusion Cloud
- Salesforce
- ServiceNow
- Workday
- Zendesk
•For initial loads:
- Salesforce Marketing Cloud
- SAP OData V2
These application ingestion and replication jobs can have any of the following target types: Amazon Redshift, Databricks, Google BigQuery, Microsoft Azure Synapse Analytics, Oracle, PostgreSQL, Snowflake, and SQL Server.
Database ingestion and replication sources:
•For all load types with any target type:
- Db2 for i
- Db2 for z/OS
- MySQL
- Oracle (log-based CDC method only)
- SQL Server (CDC tables and log-based CDC methods only)
•For initial loads with any target type:
- PostgreSQL
- SAP HANA
•For incremental loads and combined initial and incremental loads with Amazon Redshift, Databricks, Google BigQuery, Microsoft Azure Synapse Analytics, Oracle, PostgreSQL, Snowflake, or SQL Server targets:
- Oracle (query-based CDC method only)
- SQL Server (query-based CDC method only)
Previously, you could use serverless runtime environments only for application ingestion and replication initial load jobs that had a Marketo, Microsoft Dynamics 365, Salesforce, ServiceNow, or Zendesk source, and database ingestion and replication jobs that had a MySQL, PostgreSQL (initial loads only), Oracle, or SQL Server source.
You still cannot use serverless runtime environments for file ingestion and replication jobs and streaming ingestion and replication jobs.
For more information about serverless runtime environments, see Administrator > Runtime Environments > Serverless Runtime Environments and the Data Ingestion and Replication Connectors and Connections documentation for your connector.
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. The specific custom properties added 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 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 or hide 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. 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. If you add rules to exclude columns, you can now run a validation to check of the rules. The validation warns you if a 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.
For more information, see the Data Ingestion and Replication Command-Line Interface.
New Scheduled filter in Operational Insights
In Operational Insights service, 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. For more information, see "Monitoring all ingestion and replication jobs" in Operational Insights.
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-managed Iceberg tables for tasks with Snowflake targets
For application ingestion and replication jobs and database ingestion and replication jobs with Snowflake targets, you can store data and metadata in permanent Snowflake-managed Iceberg tables located in an external cloud location instead of in Snowflake tables. The external location can be in Amazon S3, Google Cloud Storage, or Azure Storage.
The external storage of data in an open format has the following benefits:
•Ability to use query processing engines other than Snowflake to process the data
•Interoperability across different data processing and analytics tools
•Better performance
•Robust security and governance
Data Ingestion and Replication automatically creates the Snowflake-managed Iceberg tables when you deploy ingestion and replication tasks enabled for Iceberg table use.
Snowflake manages the metadata and catalog for these tables. Snowflake connects to the storage location by using an external volume that stores identity and access management (IAM) information. You must create and configure the external volume beforehand.
To enable the feature, set the target custom property writerTargetTableFormat to iceberg when you configure an ingestion and replication task. Also set the writerTargetTableExternalVolumeName property to the name of the external volume you created.
For more information, see the Database Ingestion and Replication and Application Ingestion and Replication documentation for Snowflake targets.
Improved DBMI AGENT service for minimizing downtime during upgrades
A new light-weight version of the Database Ingestion agent service (DBMI Agent) that runs under the Secure Agent is available to run essential services during an upgrade. The older version of the DBMI Agent service shuts down after migrating all of the initial load and CDC jobs to the new DBMI Agent. Incremental load and combined load jobs that are performing CDC processing are stopped and restarted on the new DBMI Agent from where they last left off. Initial load jobs or combined load jobs in the unload phase are restarted from the beginning on the new DBMI Agent. Because the new DBMI Agent is available to accept tasks during the upgrade process, application ingestion and replication jobs and database ingestion and replication jobs experience minimal downtime. If the new DBMI Agent fails to start, for example, because of low memory on the Secure Agent machine, the older version of the DBMI Agent continues running for up to 24 hours to ensure no service disruption occurs while startup of the new DBMI Agent is retried.
Note:
Database Ingestion agent service logs, such as Metadata Manager, Task Container, and DBMI_Agent logs, now include the application package version to allow for easy identification of the logs' application version and for the older DBMI Agent version to run during migration to the new DBMI Agent. For more information, see "New log file names for the Database Ingestion agent service" in
The October 2025 release of Database Ingestion and Replication includes the following new features and enhancements:
Db2 for LUW Log-based CDC
Effective in the October 2025 release, this feature is available to organizations for which Informatica has enabled the feature. To request access, contact Informatica Global Customer Support.
Database ingestion and replication incremental load and combined load tasks that have a Db2 11.x for LUW source and a Snowflake target can now capture change data from the database logs. The Db2 source must be on a RedHat Linux or Windows system.
When you configure a task in the latest configuration wizard, on the Task Details page for the source, select Log-based in the CDC Method field and set the associated Catalog Table Name, Capture Threading, and Log Read Buffer Size fields. You can optionally include the tasks in a CDC staging group and use schema drift.
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, database encryption, or table partitioning. Also, the source can be in multiple-partition cluster.
This CDC method does not support the following items: sources on AIX or AWS 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.
The MongoDB source can use Community Edition version 4.x, 5.x, 6.x, or 7.x, with replica sets or sharded clusters.
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 log-based or trigger-based CDC sources is not supported. Table-level resynchronization continues to be supported.
•For table-level synchronization of SAP HANA log-based or 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.
For more information, see the Database Ingestion and Replication documentation.
Custom data-type mappings for PostgreSQL sources and Oracle targets
You can now define rules to create custom mappings of PostgreSQL source data types to and Oracle target data types if you want to override the default data-type mappings for Database Ingestion and Replication.
You can add custom data-type mapping rules on the Task Details -Target Details page when creating a task.
Custom data-type mapping rules are applied when the target table is created during task deployment and also during schema drift processing. Custom data-type mappings are not evaluated at runtime when the job loads data to the target table, with the exception of schema drift handling.
For more information, see the Database Ingestion and Replication documentation.
Query-based CDC method enabled for Oracle and SQL Server sources with serverless runtime environments
You can now use the Query-based CDC method with a serverless runtime environment for tasks that have SQL Server or Oracle sources and Amazon Redshift, Databricks, Google BigQuery, Microsoft Azure Synapse Analytics, Oracle, PostgreSQL, SQL Server, or Snowflake targets.
For more information, see the Database Ingestion and Replication documentation.