vshah
07/02/2026, 8:12 PMjirat.mee
07/07/2026, 7:31 AMian064
07/07/2026, 7:05 PMSlackbot
07/07/2026, 7:12 PMkarthick.rajan
07/08/2026, 4:09 AMPrakash Mishra
07/08/2026, 12:57 PMakhilesh.kumar178
07/15/2026, 10:39 AM_id column. The source table contains rows where _id is NULL, and Airbyte's dedup/normalization step could not process these — causing the sync to abort. I checked Postgres stores table and there was no _id column with null values. Airbyte source (postgres) setting was using update method as 'scan changes with user defined cursor'.
2. Switched to Incremental | Append — now seeing duplicate rows:
As a workaround we switched to Incremental|Append mode. Syncs now complete successfully, BUT we are seeing duplicate rows in Snowflake destination.
What's unusual: all duplicate rows for a given store have the exact same dateupdated value. The only difference between duplicate rows is _AIRBYTE_EXTRACTED_AT — spaced ~15 minutes apart (our sync frequency).
Example — 7 rows for same store in Snowflake, all identical data:
Idateupdated = 2026-07-14 12:33:17 _airbyte_extracted_at = 12:46 ← first sync
dateupdated = 2026-07-14 12:33:17 _airbyte_extracted_at = 13:03 ← duplicate
dateupdated = 2026-07-14 12:33:17 _airbyte_extracted_at = 13:17 ← duplicate
dateupdated = 2026-07-14 12:33:17 _airbyte_extracted_at = 13:33 ← duplicate
... and so on
This only affects a small number of stores (~16 out of 243K) at any given time. The affected stores change over time.
Question for community: What is causing Incremental|Append + UDC to replicate the same rows repeatedly with identical dateupdated? Is this a known behavior and is there a recommended fix short of switching to CDC?ruchin sangwan
07/17/2026, 9:05 PMVaibhav Doshi
07/21/2026, 10:28 AMPrakash Mishra
07/22/2026, 8:02 AM\u0000 as string in JSONB field rather than try to convert it to null bytes.. this is causing issue and failing pipeline...Prakash Mishra
07/24/2026, 9:03 AMd.gavrillov
07/30/2026, 7:38 AMmain . Is there a way to solve this so each destination writes to it's own branch?john roger
07/31/2026, 12:49 PMjohn roger
08/01/2026, 4:34 AMa1515899696
08/04/2026, 2:36 AMa1515899696
08/04/2026, 2:53 AMryankyaw6
08/04/2026, 3:37 PMNav Sandhu
08/04/2026, 6:17 PMd.gavrillov
08/05/2026, 5:14 PMsivaramakrishnan.govi
08/10/2026, 11:30 AM0.58.0 (OSS/Docker)
• MSSQL: source-mssql:4.0.15
• PostgreSQL: source-postgres:3.8.1
• Destination: destination-clickhouse:1.0.0
With PostgreSQL, an empty table is still included in streamStats with recordsEmitted: 0, bytesEmitted: 0, etc.
With MSSQL, the sync succeeds, but an empty table is completely absent from streamStats. Only non-empty tables are reported.
For example, with 3 tables (50k, 50k, and 0 rows):
• PostgreSQL → all 3 streams appear in streamStats
• MSSQL → only the 2 non-empty streams appear
Is there a recommended way to identify that an empty MSSQL table was successfully processed?kat251
08/10/2026, 6:40 PMwrite access to Github PR Comments?d.gavrillov
08/11/2026, 11:32 AMAryan Kumar
08/12/2026, 11:39 AMPrakash Mishra
08/24/2026, 7:58 AMMarcin Sola
09/03/2026, 11:28 AMamgad nady
09/11/2026, 12:23 AMjayasheel.kalgal
09/22/2026, 4:04 PMmarco.mancuso
09/28/2026, 9:52 AMRichelle Herrli
10/01/2026, 9:24 PM