ingestr v1.0.43 - Braze Events And UUID Copy Fixes

ingestr v1.0.43 was published on June 24, 2026, with a small set of changes that matter for ELT jobs moving Braze and Postgres data. The main operator visible fix is the Postgres UUID copy encoding change, since copy paths are where type issues tend to surface after a pipeline has already started moving rows. The release metadata does not mark this as a prerelease.

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

The Postgres fix is narrow but important. ingestr writes through copy flows, and UUID values are not useful if the encoding path mutates them or makes a bulk load fail. The changelog calls out a fix for UUID copy encoding, which points at correctness in the data movement path rather than a cosmetic connector change.

For platform teams, this is the change to test with tables that have UUID primary keys, foreign keys, and nullable UUID columns. A good smoke test is a small source table with known UUID values, a destination table loaded through the same command shape used in production, and a row count plus value comparison after the run. The release notes do not mention a migration step, so the practical check is pipeline validation rather than schema work.

ingestr v1.0.43 also standardizes connector table options behind a shared query param parser. The release notes do not list every connector touched by this parser, so it should be read as a consistency change around table option handling rather than a new source or destination surface.

This matters when pipeline definitions use table names with options in the URI or query string. A shared parser usually reduces one class of connector drift: one connector accepting an option while another rejects the same shape. It can also expose invalid options earlier if the parser is stricter than a local parser. That is a useful trade for repeatable jobs, but teams with hand built table strings should run one dry job before rolling it into scheduled work.

Braze gets the largest visible data model change in this tag. The release adds an event_series table for daily counts per custom event and moves the events table to use a richer /events catalog. Those names are worth calling out because they affect the shape of what lands downstream, not just the transport path.

The event_series table is useful when a warehouse needs volume checks, trend views, or campaign health metrics without reconstructing daily event counts from raw event streams. It gives data teams a small aggregate surface tied to custom events. The richer /events catalog should improve the descriptive side of the events table, which helps when analysts need event names and catalog metadata to line up with downstream models.

There is one caveat. The release note says daily counts per custom event; it does not say that every raw event attribute is exposed in event_series. Treat it as a metrics table, then keep raw event extraction separate where row level analysis is needed.

Two entries in the changelog are mostly integration noise: a Greptile review item and a merge entry for the incremental events endpoint branch. They are useful for maintainers, but they do not describe a separate operator action. For release readers, the safer read is that v1.0.43 is a focused connector patch with Braze data model additions and a Postgres load path fix.