ingestr v1.0.41 - BigQuery Pruning and Connector Updates

ingestr v1.0.41 was published on June 23, 2026, for bruin-data/ingestr. The release centers on BigQuery merge partition pruning, with connector work for GitLab and Braze that matters to ELT jobs moving product and marketing data into warehouses. It is not marked as a prerelease.

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

BigQuery merge pruning gets the center of gravity

The clearest warehouse change is “Optimize BigQuery merge partition pruning”. In ingestr terms, that is the release item most likely to affect the cost profile of repeated loads into partitioned BigQuery targets.

The notes do not spell out the predicate change, and that matters. Partition pruning is only useful when the merge can restrict the set of partitions BigQuery has to inspect. For operators, the right check after upgrade is not just whether the job completes. Compare bytes processed, partitions touched, and merge runtime for tables that receive incremental updates.

This is a narrow change, but it sits in a high impact path. BigQuery merge jobs can become expensive when a target table grows and the merge predicate forces broad scans. A pruning improvement is the sort of release item that may not change pipeline code, but can still change warehouse spend and schedule slack.

GitLab and Braze widen extraction coverage

The release also adds a new GitLab source. The notes do not list supported GitLab resources, so this should be treated as connector availability, not a full contract for every GitLab object. Still, adding GitLab to ingestr’s source list is useful for teams that want GitLab data loaded through the same warehouse flow as product analytics and business systems.

Braze gets a more explicit data shape. v1.0.41 adds a user_data table for segment user export. That table name is worth calling out because Braze exports often become input to audience analysis, activation audits, and customer state reconciliation. Keeping it as a named table rather than a vague export path makes downstream modeling easier to reason about.

There is also a review cleanup on user_data. The release note labels it as addressing a Greptile review, so this reads as quality work around the new Braze path rather than a separate feature. It is still relevant because new connector tables tend to fail at the boundary details: nullable fields, unusual user attributes, and export shape changes.

Operator maintenance stays small but relevant

Several items in v1.0.41 are maintenance work. The release adds a license audit lock, which is not pipeline behavior, but it does make dependency review more repeatable. For platform teams that need a clear supply chain record before promoting images or packages, that sort of lock file can remove ambiguity from a release review.

The notes also mention retry logic. No flag, config key, or target system is named, so it would be risky to read this as a broad reliability redesign. The practical takeaway is smaller: some path now has retry handling that did not exist before, and teams should watch logs after upgrade to see whether transient failures become slower but successful runs.

The fetch users then subscribe change is similarly terse. Without endpoint names or a schema note, it looks like connector sequencing rather than a new public interface. That can still matter in extraction jobs where subscription state depends on a complete user set, but the release notes do not provide enough detail to claim a wider behavior change.

The remaining lint item is internal cleanup. It is fine to say that plainly. For data engineering users, the value of this release is not lint. It is the combination of BigQuery merge pruning, new source coverage, and the Braze table.

Where to get it