CloudQuery Snowflake Destination v5.2.13 - Safer Stage Creation


CloudQuery Snowflake destination v5.2.13 was published on August 13, 2026, with a safer setup path for Snowflake stages and file formats. The destination now uses IF NOT EXISTS when creating those objects, addressing a concurrent write path that could lose data. This is a standard release, not a prerelease.

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

The main fix changes stage and file format creation so an existing object does not turn setup into a conflicting operation. That matters when several writers initialize the same destination at nearly the same time. The release notes explicitly connect the old behavior to concurrent write data loss.

Using IF NOT EXISTS narrows that race. One writer can create the shared Snowflake object while another observes that it already exists. The change is tracked in issue 23175 and implemented by commit eeb957a.

This is a focused correctness fix. The notes do not announce a new configuration key, command line flag, or schema migration. Operators running parallel syncs should still test their existing workload shape, but there is no documented migration procedure attached to the release.

The boundary matters during rollout. This patch protects object initialization; it does not announce changes to retry handling or record deduplication. A useful smoke test is to start the normal set of parallel destination jobs against the same Snowflake target and compare row counts with the source. That exercise checks the repaired race without pretending that the release changes every failure mode in a concurrent load.

Version 5.2.13 also documents staged loading and Snowpipe. That documentation work is tracked in issue 23244. The release notes do not describe a behavior change for either loading path, so this item should be read as operational guidance rather than a new ingestion feature.

The timing is useful. A release that changes stage creation also needs a clear account of how stages and Snowpipe fit into the destination path. Platform teams can use that material when reviewing object ownership, load sequencing, and runbooks, while keeping the concurrency fix itself separate from the documentation update.

The dependency set includes two updates marked as security related. google.golang.org/grpc moves to v1.82.1, while pytest moves to v9.0.3. The pytest update appears twice in the notes through separate pull requests, so it is one dependency version change rather than two destination capabilities. No CVE or advisory identifier is included in the release notes.

The Arrow update is the most directly relevant of the remaining maintenance changes. github.com/apache/arrow-go/v18 moves to v18.7.0. This is a dependency change, not an announced Snowflake feature. Regression checks should therefore concentrate on Arrow serialization, concurrent load handling, and any integration that exercises the linked gRPC code.

For operators, the upgrade case is narrow and concrete: take the concurrent setup fix, then validate the same parallel sync and staged loading scenarios already used in production. The notes identify no breaking change, but the Arrow and gRPC updates justify a normal destination smoke test before broad rollout.