Panther's Snowflake integration keeps dropping our tables. Any fixes?

We observed a similar issue last quarter, though ours manifested specifically after Panther applied certain schema additions that included new nullable columns. The `CREATE OR REPLACE` statement logging as successful while the table disappears points to a potential race condition or transaction isolation problem in the sync process.

I'd recommend setting `schema_sync: false` immediately as a stopgap to prevent further data loss. This will halt automatic DDL operations. Instead, manage schema migrations manually via version-controlled scripts executed against Snowflake outside of Panther's schedule. This introduces an approval layer.

Also, check your Snowflake query history for the exact transaction around the failed sync time. Look for any concurrent DDL operations on the same table from other tools or users, as Snowflake's locking behavior with `CREATE OR REPLACE` can sometimes be misinterpreted by external orchestration tools. Panther's managed queries might not be handling an implicit commit rollback correctly under certain error states.

That's a solid interim recommendation. Switching to manual schema management definitely removes the variable of Panther's sync logic, at least until you get to the bottom of it.

I'd add one small thing to checking the query history: also look for any `ALTER SESSION` statements that might have changed the `QUERY_TAG` or other parameters for that Panther connection. A mismatch in session settings between the orchestration tool and Snowflake's expectations can sometimes cause those implicit commits to behave unpredictably.

Let us know what you find in the logs.

That's a good point about the session settings. In a different context with a warehouse automation tool, we saw similar ghost commits happen when the QUERY_TAG was being set by two different processes, clashing mid-sync. It created a transaction boundary we didn't expect.

Is there a way to see which specific session parameters Panther's connector is using by default? The docs aren't super clear on that. I'm wondering if they're setting something like `AUTOCOMMIT=FALSE` that could interact badly with a `CREATE OR REPLACE` if another process is pinging the connection.

Turn off schema_sync right now. You're letting Panther run DDL unsupervised, which is a guaranteed way to lose data. That config is for development sandboxes, not production.

The logs are lying. A successful CREATE OR REPLACE that results in a missing table means the transaction rolled back or the session got killed, but the logging framework didn't catch it. This isn't random. Something in your environment is interfering with Panther's connection lifecycle.

Check your Snowflake account for any resource monitors or auto-suspension policies hitting that warehouse during the sync window. Also look for any other process with ownership on that same schema. This reeks of a permissions clash, not a bug.