ingestr v1.0.55 - Vitess TLS and CDC Fixes

   |   3 minute read   |   Using 501 words

ingestr v1.0.55 was published on June 30, 2026, with a focused CDC update for Vitess and Postgres users. The main change is TLS support for the Vitess CDC VStream connection, backed by a Postgres CDC fix that preserves array columns and makes BigQuery load errors visible. This release is not marked as a prerelease.

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

Vitess CDC VStream TLS support

Vitess CDC gets the headline change in v1.0.55: TLS support for the VStream connection. The release note puts this under the MySQL and Vitess path, so the practical audience is anyone running ingestr against Vitess CDC where the stream connection needs transport security.

That is a narrow change, but it is not cosmetic. CDC connections often sit on the path between production data and a warehouse or lake. If a Vitess deployment expects encrypted transport, ingestr now has support for that VStream path noted in this release.

The notes do not list new config keys, flags, or migration steps. Treat this as capability support from the release notes, not as a reason to invent a new setting name in automation. Check the release page and the project docs before changing production config.

Postgres CDC arrays stay intact

The Postgres CDC fix is about array columns. In v1.0.55, the release notes say postgres-cdc preserves array columns, which is the exact kind of data shape issue that can pass a smoke test and still break a downstream model.

Arrays are awkward because their failure mode is often subtle. The pipeline may still move rows, but a field that should carry a list can arrive missing, flattened, or changed. The release notes do not claim a wider Postgres type rewrite, so the safe reading is specific: array columns in the Postgres CDC path are the target.

For users with analytics jobs on top of replicated Postgres data, this is worth checking in validation. Compare a table with array columns before and after the load, then verify the destination schema and values. That is boring work, which is exactly why it catches real problems.

BigQuery load errors are surfaced

The same postgres-cdc change also surfaces BigQuery load errors. The wording is short, but the operator impact is clear. A load error that does not reach the person running the job is not much better than a silent failure.

This matters during backfills and CDC recovery work. When BigQuery rejects data, the useful answer is the actual load failure, not a vague result that sends someone searching through unrelated logs. v1.0.55 moves that behavior in the right direction by making those errors visible according to the release notes.

The notes do not say whether this changes exit codes, log text, or a structured error payload. Do not build monitoring rules around a guessed format from this announcement. Run a small failing load in a test environment and inspect what ingestr now reports.

Where to get it



denis256 at denis256.dev