ingestr v1.0.49 - Schema Evolution Fixes for BigQuery

   |   4 minute read   |   Using 723 words

ingestr v1.0.49 was published on June 29, 2026, and it is mostly a schema evolution fix release for data pipeline operators. The main user facing change is safer BigQuery merge behavior around integer primary keys, with smaller updates for destination specific type handling and the MongoDB driver. It is not marked as a prerelease.

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

BigQuery merge runs avoid integer primary key ALTERs

The release notes call out a schema evolution fix that stops ingestr from trying to alter integer primary key columns during repeat BigQuery merge runs. That is the change most likely to matter for operators, because merge mode is usually expected to settle into a boring rhythm once the target table exists.

The related changelog entries show the maintainers narrowing the behavior instead of applying a broad schema rule. The narrower integer skip is gated to BigQuery, numeric width suppression is gated by destination scheme, and override suppression is scoped to integer types. That points to a practical fix: avoid rewriting stable key columns while still letting the schema evolution code work where it is intended.

One detail worth noting is the split between merge behavior and generic schema evolution. The release notes do not say all BigQuery integer handling changed. They say the guard is about integer primary key columns on merge repeat runs, which is narrower and easier to reason about.

This is not described as a breaking change. There is no migration step in the notes. For teams running BigQuery merge jobs with integer primary keys, the sensible action is to read the release notes, test the same sync shape in a staging pipeline, and watch whether repeat runs stop producing avoidable schema alter attempts.

Integer overrides now have clearer mapping

Several entries tighten how ingestr handles integer type overrides. The notes say int and integer overrides now map to int64, and an integration test expects BIGINT for a :int override after that mapping. That detail is small, but it is exactly the sort of detail that decides whether a loader keeps a table stable across runs.

The same group of changes skips an alter for a narrower integer override and keeps suppression scoped to integer types. In plain terms, the release is trying to stop integer width handling from spilling into unrelated type changes. Schema evolution code is useful only when it is careful. Otherwise it turns metadata drift into a production chore.

The release also maps the common spelling variants, so a source or override that says int or integer lands on the same wider target idea. That reduces one class of small config surprises, especially when teams move recipes between sources or review generated table schemas.

Destination gates cover Snowflake and Trino

The changelog also says schema evolution gating now covers Snowflake and Trino. It also mentions float width overrides on collapsing destinations, where ingestr now skips those overrides. The wording is specific, so treat this as destination aware cleanup rather than a promise that every warehouse path changed.

This matters because type rules are rarely portable across warehouses. BigQuery, Snowflake, and Trino do not always want the same column shape for the same logical source type. The release notes suggest the maintainers are making those decisions closer to the destination scheme, which is the right place for them.

Float width handling gets similar treatment. The notes say ingestr skips float width overrides on collapsing destinations, which reads like another guard against changing a destination column for a type detail that should not drive an alter.

MongoDB driver maintenance

ingestr v1.0.49 also bumps go.mongodb.org/mongo-driver to v1.17.7 and updates the license audit lock for that driver version. That is maintenance work, but it still matters for teams that track dependency versions in container images, SBOM output, or internal approval lists.

The release notes do not call out a security fix for the MongoDB driver. So the right reading is plain dependency upkeep unless the upstream driver notes matter to your own policy.

The remaining notes are small code hygiene changes around DestinationScheme comments. They are worth recording, but they are not the reason most users will schedule this update. The schema evolution fixes are the operational part of the release.

Where to get it



denis256 at denis256.dev