ingestr v1.1.28 - Snowflake CDC Destination

ingestr v1.1.28 was published on August 13, 2026. The release adds a Snowflake CDC destination, which is the only runtime feature named in its short changelog and the change that matters for data pipeline operators.

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

The release notes describe the main change in five words: Snowflake CDC destination. That establishes a useful but narrow fact. Version v1.1.28 adds destination support for change data capture work that targets Snowflake.

The notes do not say which source connectors can feed this path. They also do not specify table creation behavior, schema mapping, checkpoint storage, replay semantics, or failure recovery. No CLI flag, configuration key, or file path is listed. Those omissions should set the boundary for any deployment decision.

CDC pipelines commonly depend on ordered application, durable resume state, and predictable handling of repeated events. The changelog makes no claim about any of those properties. Operators should therefore read this as a new destination surface, not as a complete operating contract for every CDC topology.

That distinction matters most for existing ingestr deployments. A destination can be present while a particular source and schema combination still needs validation. The release notes provide no compatibility matrix, so production acceptance should use the same source, data types, and Snowflake object layout that the real pipeline will use.

There are three records in the changelog. One implements the Snowflake CDC destination. One merges that work. The final record fixes lint. The merge is delivery history rather than another operator feature, while the lint fix is repository maintenance.

No other source connector, destination, data type conversion, CLI behavior, or performance change is named. There is also no security fix in the notes. This makes v1.1.28 easier to classify than a broad connector release: its public scope is the Snowflake CDC destination, with a small amount of internal cleanup around it.

That narrow scope does not prove a narrow runtime impact. Destination code sits where transport, schema conversion, writes, and recovery meet. It does mean the release notes offer no evidence for changes outside that path. Operators comparing this version with an earlier deployment should keep their review centered on Snowflake CDC behavior.

This is a regular release, not a prerelease. The notes document no breaking change and provide no migration procedure. They also include no example command or configuration, so there is nothing in the published record that supports a blind configuration change.

A staged run should answer the questions left open by the changelog:

  • Verify that a representative CDC stream reaches the expected Snowflake objects.
  • Check inserts, updates, and deletes with the data types used in production.
  • Restart the job and confirm that resume behavior matches the pipeline contract.
  • Replay a small event range and inspect the result for duplicates or missed changes.
  • Capture destination errors and Snowflake query history before raising throughput.

These are validation steps, not features claimed by the release. They are the minimum evidence needed when a changelog names a destination but omits its operating semantics. Keep the previous ingestr version available until replay and restart tests pass for the actual workload.