ingestr v1.0.50 - Postgres CDC Keepalive Fixes

ingestr v1.0.50 was published on June 29, 2026, as a stable release for bruin-data/ingestr. The main change is in Postgres CDC, where the connector now keeps the walsender alive during the destination write phase and sends a keepalive immediately on start. For operators, this release is about reducing CDC liveness risk when the downstream write path is slower than the source stream.

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

The Postgres CDC fixes are the part of v1.0.50 that matter most for production ELT jobs. The release notes call out a change to keep the walsender alive during the destination write phase. That is a narrow fix, but it sits in the part of a CDC pipeline where source liveness and sink latency can disagree.

A CDC job can still be healthy while it is busy writing records into the destination. The source connection does not know that unless the connector keeps sending liveness traffic. If keepalive traffic pauses while the destination write path is busy, Postgres can see the replication side as stale even though the job is still doing useful work.

The second CDC fix sends a keepalive immediately on start. That closes another small gap. Startup is often where operators see confusing symptoms: a slot is active, the job exists, but the first useful signal has not arrived yet. This release makes that first signal explicit earlier in the run.

The BigQuery change protects the knownDatasets map from concurrent writes. That points at a Go level failure mode rather than a semantic change in BigQuery itself. A shared map that is written from more than one execution path can fail hard under load, especially when several tables or streams are being prepared at once.

The notes do not say which exact workload triggers the race. Read the fix as concurrency hardening around dataset tracking. For data engineers, the relevant question is not whether BigQuery SQL changed. It did not, based on the release notes. The relevant question is whether parallel ingestion into BigQuery can now avoid a local process failure while resolving or recording known datasets.

This is not a new connector feature. It is a reliability fix in the destination path. That distinction matters during rollout because the expected signal is fewer local failures, not different destination data.

v1.0.50 is not marked as a prerelease, beta, alpha, or release candidate. The notes also do not call out migrations, new config keys, new CLI flags, backfills, or breaking behavior. Treat this as a narrow patch release.

For Postgres CDC jobs, watch replication slot lag, walsender disconnects, job restarts, and destination write latency before and after the upgrade. The commit messages in the release notes suggest the fix is aimed at liveness while data is being written downstream, so those are the operator signals that should move if the previous version was hitting the bug.

For BigQuery, watch worker crashes and failed runs around dataset preparation. If the prior failure mode was a concurrent write to knownDatasets, the improvement should show up as fewer process level failures rather than a visible schema change. Existing warehouse tables should not need special handling based on the notes provided for this release.

The merge entry in the changelog is integration bookkeeping. The externally visible changes are the two Postgres CDC keepalive fixes and the BigQuery concurrency guard.