Ingestr v1.0.33 - Db2 Source and BigQuery Loader Fixes

   |   3 minute read   |   Using 489 words

Ingestr v1.0.33 adds a native Db2 source and ships several fixes for BigQuery, Databricks, and SQL Server loaders. The release landed on June 15, 2026 as a stable build, not a prerelease. For operators running mixed enterprise databases, the Db2 connector is the item worth upgrading for first.

The full release notes and downloads are on the GitHub release page.

Native Db2 source

The headline connector change is a native Db2 source, merged in pull request #790. Teams that still run IBM Db2 as a system of record can point ingestr at that database without a custom wrapper or an intermediate export step.

If you already use ingestr for other relational sources, the Db2 connector follows the same ingestion model. Configure the source, pick tables or queries, and run your usual destination pipeline. That keeps staging logic, incremental settings, and destination mappings consistent with Postgres, MySQL, or SQL Server jobs you already maintain.

Check the project docs for connection parameters and any Db2 specific options before you cut over production jobs. A staging run against a small table subset is enough to confirm credentials and type mapping before you schedule a full sync.

BigQuery loader reliability

Two changes in this release target BigQuery pain points that show up under load.

Duplicate query jobs are now handled explicitly (#798). When the same BigQuery query job is submitted more than once, ingestr no longer leaves operators to untangle conflicting job state by hand.

Parquet load batches are cast to the staging table schema before they land (#799). That closes type mismatches between Parquet files and the staging table definition, which otherwise surface as opaque load job failures.

Together these fixes matter for pipelines that batch Parquet into BigQuery staging tables and rerun jobs after partial failures. Neither change alters your CLI flags or config keys, but they remove two common failure modes that show up when schemas drift or jobs are retried.

Databricks and SQL Server fixes

Databricks users get a targeted decode fix (#794). JSON array fields that previously failed during decoding should now parse correctly on read. If you saw garbled or missing array values from Databricks sources, retest those tables on v1.0.33 before you blame the warehouse export layer.

SQL Server sources with multipart tables gain first class support (#796). Large tables split across multiple physical partitions can be ingested as a single logical source instead of requiring manual per partition workarounds. That is useful when a single table spans filegroups or partition schemes and you want one ingestr table definition to cover the full dataset.

CI and internal changes

The changelog also lists release CI updates: Docker tests now gate releases, and an scd2 test fix landed. These do not change runtime behavior for most users, but they explain why this tag ships with a slightly longer commit list than the five user facing items above.

Where to get it



denis256 at denis256.dev