Decaf Blog Data pipelines, open-source tooling, reverse engineering, and systems notes

ingestr v1.0.50 - Postgres CDC Keepalive Fixes

3 min read

ingestr v1.0.50 was published on June 29, 2026, with a narrow reliability release for Postgres CDC and BigQuery destination state. The main change is keeping the Postgres walsender alive while destination writes are in progress, which matters when a load path is slower than the replication stream expects.

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

Postgres CDC keepalive behavior

The most useful change in ingestr v1.0.50 is the Postgres CDC fix for keeping walsender alive during the destination-write phase. That phase is where a pipeline can look quiet to the upstream database even though work is still happening downstream. If the destination write takes time, the replication side still needs signs of life.

For data engineers, this is less about feature surface and more about failure shape. CDC jobs often fail in the space between source read and destination commit. A slow warehouse write, network variance, or a large batch can make the source side think the client is idle. Keeping walsender alive during the write path reduces that class of interruption.

The release notes also mention a keepalive sent immediately on start. That is a small detail, but it matters for startup behavior. A CDC task can spend time setting up state before useful rows appear. Sending keepalive traffic at the beginning gives the replication connection an earlier heartbeat instead of waiting for later activity.

BigQuery dataset cache under concurrency

The BigQuery fix protects the knownDatasets map from concurrent writes. In practical terms, this is a shared state guard around destination metadata. A map that tracks known datasets is useful for avoiding repeated checks, but it becomes a risk when concurrent execution can write to it at the same time.

This kind of bug is usually not visible as a clean data contract problem. It tends to show up as intermittent failures under parallel load. One run passes, the next run fails in the destination setup path, and the actual issue is not the schema itself. It is state mutation around the schema handling.

For ELT operators using BigQuery as a target, the change is worth noting because destination metadata code sits on the hot path of table creation, dataset discovery, and load preparation. The release notes do not describe a schema behavior change, so this should be read as a correctness and stability fix rather than a new BigQuery feature.

Operator notes for this release

This is not marked as a prerelease. It is a normal release, and the GitHub release page lists a compact changelog rather than a broad upgrade guide.

The release does not advertise new connectors, new CLI flags, or changed configuration keys. That makes the upgrade decision fairly narrow. Teams running Postgres CDC should pay attention first, especially if they have seen lag growth or disconnects while writes are happening downstream.

Teams using BigQuery should treat the knownDatasets fix as a concurrency risk reduction. It does not imply a different table model or warehouse layout. It does suggest that previous versions could hit unsafe shared state when multiple paths touched dataset tracking at once.

There are no breaking changes called out in the notes. Still, CDC releases deserve a controlled rollout. Run one representative Postgres source through the same destination path before moving every stream. Watch replication lag, destination write time, and restart behavior during the first scheduled runs.

Where to get it