Direct Answer
No. Liquibase does not provide a configuration to bound the number of records processed per transaction within a single loadUpdateData change set. The entire CSV is handled as one logical operation, with no native pagination or offset mechanism for the source file.
Recommended approach: Split the source CSV into smaller files and apply them through separate change sets or separate Liquibase runs. Increasing JVM heap with -Xmx only delays OutOfMemoryError, because memory usage scales with CSV size and primary-key lookup overhead rather than remaining bounded.
Likely Explanation vs. Confirmed Facts
Confirmed: There is no built-in row limit or chunking inside a single loadUpdateData change set.
Likely explanation: Heap exhaustion occurs during the primary-key lookup phase. To decide whether to insert or update, Liquibase must match each row's primary key against the target table, and on massive datasets this matching accumulates state that is not released until the change set finishes. This is separate from JDBC driver batching, which controls statement transmission to the server, not CSV parsing or in-memory key matching.
Steps for This Case
- Split the CSV into chunks of roughly 10,000–50,000 rows, ensuring primary-key uniqueness is preserved across chunks to avoid duplicate-key or conflicting-update errors.
- Run each chunk as its own change set, or invoke Liquibase once per chunk, so memory is capped per execution.
- If the insert/update logic can be reformulated, load the CSV into a staging table with a database-native bulk loader and merge with SQL. This avoids Liquibase's in-memory PK matching entirely.
Even if the JVM survives, one massive transaction can cause table locks, transaction-log growth, and connection timeouts. Splitting the work also reduces these database-side risks.
Verification
Memory behavior is version-sensitive. Verify against your specific Liquibase release before relying on a fixed chunk size. A conservative reproduction uses a representative CSV with a constrained heap and a heap dump:
java -Xmx512m -XX:+HeapDumpOnOutOfMemoryError -jar liquibase.jar update
Inspect the dump to confirm whether the PK lookup phase is the dominant consumer. Then split the file and monitor heap usage across separate runs to confirm stability.
Missing Diagnostic Detail
Which Liquibase version are you running? If your release includes documented changes to loadUpdateData streaming or batching, the chunking threshold or an alternative configuration may apply.
liquibase