ingestr v1.0.62 - Iceberg Destination and CDC Update

   |   3 minute read   |   Using 568 words

ingestr v1.0.62 was published on July 2, 2026, for bruin-data/ingestr. The practical headline is a new Apache Iceberg destination, backed by Vitess and PlanetScale CDC work in the MySQL path. For operators asking what changed in ingestr v1.0.62, this is a small release with one new destination and one CDC area that deserves a careful config review.

The full release notes and downloads are on the GitHub release page. The GitHub metadata does not mark this as a prerelease.

Apache Iceberg destination

The first user visible change is the Apache Iceberg destination. The release notes do not give usage details, so this post should not pretend there is a new flag, file path, or documented config block. What matters is the support boundary: ingestr can now target Iceberg as a destination in this release line.

For teams using ingestr as a simple data movement tool, destination support is where operational choices start. A new destination can affect table layout, catalog setup, permissions, and write behavior. The changelog only says “Add Apache Iceberg destination”, so treat the release page as the source of truth and test with a narrow pipeline before moving an existing job.

This is also a useful reminder that destination changes are rarely only about syntax. The hard parts usually sit around credentials, storage permissions, catalog access, and how failed writes recover. The release notes do not describe those details, which means the sane rollout path is a small job first, then broader adoption after the write path is understood.

Vitess and PlanetScale CDC

The second important change is the MySQL CDC overhaul for Vitess and PlanetScale. That is the kind of note that looks small in a changelog but matters in production, because CDC code sits on binlog semantics, resume state, and edge cases around schema changes.

The release note names Vitess and PlanetScale together. That is useful context for operators who route MySQL compatible data through those systems instead of a plain upstream MySQL server. It also means this release is worth testing with data that behaves like production, not only with a fresh empty table.

There is also a merge entry for PR #911 around the PlanetScale CDC review. The release notes do not make that a separate user feature, so it should be read as process context around the same CDC area. Not every changelog line needs its own upgrade step. This one reinforces that the MySQL CDC path is the part to inspect closely.

Upgrade notes

The sharpest upgrade detail is the rename of the planetscale scheme to ps_mysql. If current configs, secrets, docs, or runbooks use planetscale, review them before rollout. The notes do not say whether the old scheme still works, so assuming compatibility would be lazy and expensive.

This is also where a small release can cause a loud failure. URI schemes often live outside the codebase: in schedulers, CI variables, secrets managers, or copied examples. Search those locations as part of the upgrade, not only the repository.

The release notes do not call out breaking changes, deprecations, or a migration guide. That keeps the public signal short, but the scheme rename is still enough to justify a preflight check. If a pipeline depends on PlanetScale CDC, verify the connection string and run a small CDC sync before the normal schedule takes over.

Where to get it



denis256 at denis256.dev