Hello! I am using open-source Airbyte. The connection is between Postgres(v3.7.0, update method:xmin) to Snowflake(v4.0.28), with the tables set to incremental append+deduped sync mode. I am seeing that sometimes, the records are getting synced normally, whereas, sometimes it is showing 0 records synced, but still showing success, even when our Postgres is active and has new records. The activity seems to be unpredictable. Any debugging suggestions, please? Thank you in advance.

There are similar reports in the knowledge sources where Postgres → Snowflake incremental/CDC syncs intermittently emit 0 records while the job is marked as succeeded. However, the docs and threads don’t give a single definitive root cause; they mainly suggest ways to narrow it down and configuration areas to inspect. Here’s what is covered and what you can do next: 1. Confirm whether this is a CDC / WAL resume issue (even with xmin) There are recent cases where Postgres CDC jobs suddenly start outputting 0 records with no obvious errors. In one such case, Airbyte support identified that the Postgres source was timing out while searching for the WAL resume position, and increasing the Initial Waiting Time in Seconds (Advanced) on the Postgres source resolved it. [[CDC 0 records issue](https://github.com/airbytehq/airbyte/issues/50435); [Timeout fix](https://github.com/airbytehq/airbyte/issues/50435)] - Even though you’re using

xmin

, it’s worth: - Checking the Advanced settings of the Postgres source for any timeouts related to initial waiting / resume. - Looking in the source logs around the start of the sync for any mention of waiting for WAL / resume position / timeouts. 2. Look for “successful but 0 records” patterns in logs There are multiple forum posts where: - Syncs show as Succeeded but emit 0 records. [[Sync 0 records](https://discuss.airbyte.io/t/1112); [First sync ok, then 0 bytes](https://discuss.airbyte.io/t/3135)] - In some cases, the logs show connection pool timeouts (Hikari) or other transient DB issues, but the overall job is still marked successful. [[Sync 0 records](https://discuss.airbyte.io/t/1112)] For your connection, I’d specifically: - Download the full job logs for a run that shows 0 records. - Search for: -

ERROR

or

WARN

lines from the source container. - Any

HikariPool

/ connection timeout messages. - Any messages about CDC / WAL / replication slot / resume position. 3. Check that incremental state and cursor are behaving as expected For Incremental | Append + Deduped, Airbyte: - Uses a cursor field (e.g.,

updated_at

) to decide what’s “new or modified”. - Only syncs records where the cursor value is greater than the last stored cursor. [[Incremental deduped](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes/incremental-append-deduped)] If the state is ahead of your actual data (e.g., due to a one‑off issue), subsequent syncs can legitimately emit 0 records while still being “successful”. To debug this: - In the UI, inspect the stream configuration and confirm: - The cursor field is what you expect. - The primary key is correctly set (needed for deduped mode). [[Incremental deduped](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes/incremental-append-deduped)] - Compare: - The max cursor value in Snowflake (in the final table or history table). - The actual data in Postgres (e.g.,

SELECT max(updated_at) FROM table;

). - If the stored cursor is ahead of Postgres data, that would explain 0‑record runs. 4. Use history vs final tables to see if data is being emitted but then deduped away In Incremental | Append + Deduped: - The history table can contain multiple rows per primary key. - The final table is deduped to one row per primary key, based on the cursor. [[Incremental deduped](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes/incremental-append-deduped)] When you see a “0 records” run: - Check whether any new rows appeared in the history table in Snowflake. - If history has new rows but the UI shows 0 emitted, that suggests a reporting/metrics issue. - If history also has no new rows, the source truly emitted nothing. 5. Check for known intermittent Postgres sync issues Other users have seen: - Some tables not syncing at all in a “successful” job, only to work again when moved to a separate connection. [[Some streams not synced](https://discuss.airbyte.io/t/2049)] - CDC jobs that periodically fall back to full resyncs or behave inconsistently when WAL handling is fragile. [[Stack syncs CDC](https://discuss.airbyte.io/t/2675)] Given that your behavior is “unpredictable”, it may help to: - Create a separate connection with just 1–2 problematic tables and see if the issue reproduces more clearly. [[Some streams not synced](https://discuss.airbyte.io/t/2049)] - Run syncs more frequently to reduce the window where WAL / xmin state might be lost or invalidated. [[Stack syncs CDC](https://discuss.airbyte.io/t/2675)] --- Because the knowledge sources don’t include a step‑by‑step guide for your exact Postgres v3.7.0 (xmin) → Snowflake v4.0.28 setup, I can’t point to a single fix. But as a concrete next step: 1. Grab logs from: - One normal run (with records). - One 0‑record run. 2. Compare: - Any differences in source‑side warnings/errors. - Any mentions of CDC / WAL / resume / timeouts. 3. Check cursor values in Postgres vs Snowflake for one affected table. If you can share (sanitized) snippets of those logs and the cursor/PK configuration for one table, I can help you interpret them within the constraints of the available docs.

I’m having the same issue with a connection from S3 to BigQuery.

@Fabio Lopes Did you find any solution? For now I just wrote a DAG that checks the sync after an hour and reruns it through the API if it didn't sync any thing.

It appears to have been a server-side issue on my end. The system wasn’t handling the data volume and was failing silently. After increasing the memory, it worked.