ingestr v1.0.44 - Streaming Sources and Braze Series

   |   4 minute read   |   Using 692 words

ingestr v1.0.44 was published on June 24, 2026, with streaming platform sources as the main user visible change. The release also extends the Braze source with more series tables, so teams moving event and marketing data through ingestr have a wider surface to sync. It is not marked as a prerelease.

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

Streaming platform sources are now part of the release

The largest item is “Add streaming platform sources” in the changelog. The notes do not name each platform in this release entry, so the practical reading is simple: ingestr has gained another source category, and operators should confirm exact connector names and options in the project docs or the source code for this tag.

For users, this matters when ingestr is already the path for moving SaaS and product data into a warehouse. Streaming platform data often sits beside batch oriented app data, but it usually needs separate tooling. This release points toward less split plumbing for those teams. Keep the first rollout boring: pin v1.0.44, run the new source against a small target, and verify row counts before expanding schedules.

There is also dependency work tied to these sources. The changelog says licenses.lock.yml was updated for streaming source dependencies, and THIRD_PARTY_LICENSES.txt was regenerated. That is not a feature you feel at runtime, but it is useful for anyone who has to pass license review before deploying a new connector.

Braze gets more series data

Braze receives the other visible product change. The release adds campaign_series and canvas_series tables, then adds sessions, purchase, and segment series tables. That is a meaningful expansion if Braze data is part of attribution, lifecycle reporting, or customer analytics.

The important detail is that these are series tables. They help when a pipeline needs more than account level or object level state. They are useful for trend reporting, campaign performance checks, and joins where timing matters. The changelog is terse, but the shape is clear: this release gives Braze users more granular objects to sync without building a side extractor.

There is one related cleanup: Braze series comments are trimmed to at most two lines. That sounds small, and it is. It still matters in generated schemas because long comments can make warehouse catalogs noisy. Shorter comments usually make inspection easier and reduce accidental formatting weirdness in downstream docs.

Better handling for skipped segments

The release includes a logging fix for skipped segments with a non string id. This is the kind of change that mostly helps when something is already going wrong. Instead of leaving operators guessing, the pipeline should now log that skip case more clearly.

This does not read like a behavior change for valid data. It reads like observability around bad or unexpected input. That distinction matters. Users should not expect a new segment sync mode from this note, but they can expect better evidence when segment data has an id type that ingestr does not handle.

For scheduled jobs, better skip logs reduce the usual tax of debugging partial loads. A skipped record is annoying. A skipped record with no useful context wastes time. This fix is aimed at that second problem.

Internal cleanup stays close to dependencies

Several changelog lines are maintenance work: adding DataDog/zstd to licenses.lock.yml, updating the license lock file, regenerating THIRD_PARTY_LICENSES.txt, and fixing the license test. These are not headline features, but they are tied to the new source work.

The useful operator takeaway is that the release seems to include the dependency metadata needed for the new streaming source set. If your organization audits third party packages, compare the lock file and generated license text during review. If you package ingestr into an internal image, also make sure the license artifacts in that image come from this tag.

There are no breaking changes or migration steps listed in the notes. There is also no prerelease flag on the GitHub release. Treat it as a normal patch release, but test any newly added source in isolation before putting it into an existing production schedule.

Where to get it



denis256 at denis256.dev