I have a sync with only incremental refreshes. It is failing with error "Failure in destination: Failed to drop table without the CASCADE option. Consider changing the drop_cascade configuration parameter". Why do I need to enable cascade drops with incremental refreshes?

The knowledge sources don't contain enough information to fully explain why an incremental sync would trigger a

DROP TABLE

operation requiring CASCADE. However, I can share what the knowledge sources do tell us: The

drop_cascade

option in the Postgres destination is described as: > "Drop tables with CASCADE. (WARNING! Risk of unrecoverable data loss)" [Postgres reference] The error you're seeing occurs when Airbyte tries to drop a table but finds dependent objects (such as views) that depend on it. PostgreSQL requires the

CASCADE

option in that case. The Airbyte docs note: > "The connector sometimes needs to recreate the tables; if you have created dependent objects, Postgres will require the connector to run drop statements with CASCADE enabled." [Postgres dependent objects] A related known issue confirms this can happen even unexpectedly — for example, if a view exists in the destination schema with the same name as a synced stream, a

DROP TABLE IF EXISTS

will fail with a PostgreSQL error. [fix PR] Why might this happen with incremental syncs? The knowledge sources don't explicitly explain why a pure incremental sync would trigger a table drop. Possible causes not directly covered by the sources include: • A view or other dependent object exists on the destination table. • A schema migration or table recreation is being triggered internally. Recommendations: 1. Check for dependent objects (views, materialized views, foreign keys) on the destination table in your Postgres database. 2. If you have dependent objects, the docs strongly recommend using a tool like

dbt

with an orchestrator to recreate them, and then enabling

drop_cascade

— but be aware this will also drop those dependent objects during each sync. [Postgres dependent objects] 3. If you don't have intentional dependent objects, this may be a bug worth reporting to the Airbyte team. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

Here is something suspicious. This sync was running successfully without cascade drops until the following event occurred: "Schema updated: Airbyte applied a change in the schema: 1 stream changed." There is 1 new field in the Contact stream (Referral_Slug__c). It seems like this schema update might have caused my issue - can you suggest some reasons why? Note that I have "propagate field changes only" in the schema change setting for this connection. @kapa.ai

The screenshot you've shared shows a schema update event where Airbyte detected and applied a new field (

Referral_Slug__c

) to the

Contact

stream. With "Propagate field changes only" enabled, Airbyte automatically propagates column/field additions to the destination. [Schema change management] Here is what the knowledge sources tell us about what happens when a new field is added: > "The new field will be created in the destination. Values for the field will be filled in for the updated rows." [Schema change management] However, the knowledge sources do not explicitly explain why propagating a new field (an

ALTER TABLE ADD COLUMN

type of operation) would trigger a

DROP TABLE

requiring CASCADE. That said, there is a relevant clue from the Postgres destination changelog: > Version 3.0.6 (2026-01-06): "Fix: Only apply CASCADE to DROP COLUMN, not ALTER COLUMN TYPE during schema changes." [Postgres changelog] This suggests that schema change propagation can trigger DROP operations in the Postgres destination under certain circumstances (e.g., column type changes or column drops). If your Postgres destination version is older than 3.0.6, a schema change event could incorrectly trigger a CASCADE drop even for non-destructive changes. My suggestion: 1. Check your

destination-postgres

connector version. If it is older than 3.0.6, upgrading it may resolve the issue, as that version specifically fixed incorrect CASCADE behavior during schema changes. 2. Check for dependent objects (views, etc.) on the

Contact

table in your destination, as their presence would cause any DROP operation to fail without CASCADE. [Postgres dependent objects] The knowledge sources do not provide a more specific explanation of why adding a new field would trigger a DROP TABLE, so I'd recommend also checking the Airbyte GitHub issues or contacting Airbyte support for a deeper investigation. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.