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

ingestr v1.0.64 - Snowflake Deadlock Fix

3 min read

ingestr v1.0.64 was published on July 2, 2026, with a focused Snowflake fix for multi table writes that could deadlock when the connection pool was exhausted. This is not marked as a prerelease, and the practical point is simple: concurrent Snowflake table writes should no longer stall on pool starvation in this release.

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

Snowflake writes stop blocking on the pool

The release notes name one functional fix: Fix Snowflake multi-table write deadlock from connection pool exhaustion. For data teams, this is the part that matters. A loader that writes more than one table at a time can consume every connection in a pool. If the code path then waits for another connection while holding resources needed by other writes, progress can stop without a clean error.

That kind of failure is awkward because metrics may show work in progress while the job is actually waiting forever. v1.0.64 narrows the release around that failure mode. The notes do not describe a new connector, a schema option, or a CLI flag. They describe a correctness fix in the Snowflake destination write path.

Why this matters for ELT jobs

Snowflake is often used as a shared landing and serving warehouse. Ingest jobs may load several source tables into the same target connection profile, especially when a source maps to many resources or when a batch run fans out across tables. A connection pool bug in that path does not just slow one table. It can hold the whole run.

The operator impact is therefore about reliability, not features. A deadlock can hide behind normal retry logic because no exception is raised at the useful boundary. It can also distort schedule behavior: the next run may wait behind the stuck run, queue depth grows, and warehouse slots stay tied to work that is no longer moving.

This release is worth prioritizing where ingestr writes multiple Snowflake tables from one process or one orchestration task. It is less relevant for deployments that do not use Snowflake, or that only run one table write at a time.

Changelog is intentionally small

The changelog has a second entry for a merged pull request, but that is bookkeeping rather than a separate behavior change. There are no documented migration steps, breaking changes, source connector changes, or new configuration keys in the published notes.

That matters for change review. The safest reading is that v1.0.64 should be evaluated as a targeted Snowflake destination fix. If you need to justify the update in a controlled platform, the GitHub release page gives a compact audit trail: one Snowflake deadlock fix and the merge entry that carried it.

Operational checks after upgrading

There are no upgrade instructions in the release notes. A useful validation pass is still straightforward. Run an ingestr job that writes several Snowflake tables through the same pool, then watch whether the process drains all table writes and exits cleanly. If the old failure affected your environment, this test should be closer to the real workload than a one table smoke test.

Also check scheduler behavior around any previously stuck tasks. A deadlock fix removes the software cause, but existing orchestration state may still have old blocked runs, held locks, or retry windows that need normal cleanup. The release notes do not say ingestr changes scheduler state or warehouse objects.

Where to get it