ingestr v1.0.64 - Snowflake Write Deadlock Fix

ingestr v1.0.64 was published on July 2, 2026, with a focused Snowflake fix: multi table writes no longer deadlock from connection pool exhaustion. For data engineering teams that run ELT jobs through bruin-data/ingestr, this release is about write reliability rather than new connector surface area. The metadata marks it as a stable release, not a prerelease.

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

The changelog names one user visible fix: Snowflake multi table writes could deadlock when the connection pool was exhausted. That is the whole functional story in v1.0.64, and it is enough to matter for scheduled ELT workloads that write several tables in one run.

A deadlock in this part of the path is worse than a clean write failure. A failed task can be retried by the orchestrator, reported in a normal alert, or isolated to one dataset. A blocked task can hold a worker slot, hide real progress, and leave the next run fighting the same resource pressure.

The release notes do not describe a schema change, new flag, or new Snowflake option. Treat this as a reliability patch for an existing write mode. The second changelog line is only the merge record, not a second operator facing feature.

The useful detail is the cause named in the release note: connection pool exhaustion. That points the failure at local resource contention in the write path rather than a general Snowflake outage or a malformed SQL query.

For operators, that distinction changes the first place to look during incident review. If a pipeline was hanging during Snowflake writes before this release, check whether the job opened several table writes in the same ingestr run and whether connection limits were being hit under load. The fix belongs in the client side handling of pooled connections, so warehouse sizing alone would not be the clean answer to this class of failure.

This also means the release is relevant even if average Snowflake write volume looks normal. Pool exhaustion often shows up at concurrency edges: a larger batch, a backfill window, or an orchestration run that starts several similar jobs at the same time.

The direct gain is simpler failure behavior around Snowflake writes. A data pipeline that used to sit in a deadlocked state should have less chance of getting stuck on pooled connection pressure during multi table output.

That matters for teams that treat ingestr as a small transport layer inside Airflow, Dagster, cron, or another scheduler. The scheduler can only make sane decisions when the process exits, reports a failure, or finishes. A deadlocked write path breaks that contract.

There is no evidence in the release notes of new destination semantics, changed table naming, or altered load format behavior. No migration step is listed. The conservative upgrade plan is to move staging jobs that write multiple Snowflake tables first, then watch duration, retry count, and any logs around connection acquisition.

v1.0.64 is not a broad ingestr release. It does not claim new sources, new destinations, or a changed CLI surface. That is useful to say because small patch releases are easy to overread when they land near a production symptom.

The narrow scope is also why this post does not list three unrelated changes. The release notes provide one functional fix, and the meaningful engineering surface is the affected destination, the affected mode, the named resource limit, and the deadlock behavior. Anything beyond that would be guesswork.

If Snowflake is not in your ingestr estate, this release is routine maintenance. If Snowflake multi table writes are part of a production ELT path, the GitHub release page is worth reading before the next batch window.