@kapa.ai I have a Snowflake destination that breaks every time there's a schema change. I can't give table ownership to airbyte's role. Is there a way to fix this without granting ownership? All the replications are full append

The knowledge sources don’t describe a fully supported way to run the Snowflake destination without OWNERSHIP while still being robust to schema changes, so the following is based only on what is explicitly documented and discussed. 1. Why OWNERSHIP is requested Airbyte’s Snowflake destination role is expected to have OWNERSHIP so it can freely create and manage objects (including renames and swaps) in the target database/schema. [[Snowflake forum](https://discuss.airbyte.io/t/785)] When you don’t grant OWNERSHIP, operations the connector relies on (e.g., certain ALTER/CREATE patterns) can fail, which is likely what you’re seeing when schemas change. 2. What’s officially recommended In the forum discussion, the Airbyte team’s recommendation is: - Create a dedicated database for Airbyte and give the Airbyte role OWNERSHIP there, so it doesn’t conflict with other roles that need OWNERSHIP on your main DB. [[Snowflake forum](https://discuss.airbyte.io/t/785)] That is the only concrete, documented workaround for the OWNERSHIP requirement in the provided sources. 3. Trying with reduced privileges One user asked if they could get away with just

CREATE/ALTER

etc. instead of OWNERSHIP; the Airbyte team replied that the “safest way” is still a dedicated DB with OWNERSHIP, and did not confirm that reduced privileges are supported. [[Snowflake forum](https://discuss.airbyte.io/t/785)] So there is no documented guarantee that running with less than OWNERSHIP will work reliably, especially across schema changes. 4. Interaction with schema changes / full-append The docs and issues we have focus on: - Schema-change detection and propagation at the Airbyte connection level (how new/removed columns/streams are handled). [[Schema change mgmt](https://docs.airbyte.com/platform/using-airbyte/schema-change-management#detect-and-propagate-schema-changes-connection-setting)] - A Snowflake issue where

Full Refresh | Overwrite

uses

ALTER TABLE ... SWAP WITH

, which interacts badly with Snowflake future grants. [[Snowflake grants issue](https://github.com/airbytehq/airbyte/issues/68681)] Your case is Full Refresh | Append, so the specific SWAP/grants problem doesn’t apply directly, and the sources don’t describe a separate, supported permission pattern for that mode. --- Given the available information: - There is no documented, supported configuration in these sources that avoids OWNERSHIP entirely while guaranteeing stable behavior under schema changes. - The only recommended way to “fix this without breaking other ownership requirements” is to: - Put Airbyte in its own Snowflake database (or at least its own schemas), and - Grant OWNERSHIP to the Airbyte role there, isolating it from your other roles. [[Snowflake forum](https://discuss.airbyte.io/t/785)] If you need something more fine‑grained than that (e.g., strictly no OWNERSHIP at all), the knowledge sources do not provide enough detail to confirm a safe alternative.

@kapa.ai I specifically don't want to grant ownership because of the future grant issue. Is it fully safe with full append, even in case of schema changes?

A message from kapa.ai