I have 1 source-s3 to postgres connection. S3 having just 1 CSV with 417 rows with 'scheduled' sync every 24 hours. Job runs at 6.37pm everyday without issue and I can see 417 rows in postgres. But something happens between 9pm and 9am, that same table always shows 390 rows(not 417). I setup trigger for any insert/modify/delete rows operation on that table and it did not capture anything. How to explain this? Can Airbyte or Postgres doing some internal cleaning/truncating and how to troubleshoot this weird issue?

Based on the shared material, there’s no explicit description of Airbyte or Postgres “internally” deleting or truncating rows hours after a successful sync, so this behavior is not clearly explained by the docs. A few relevant points we do know: 1. Airbyte’s S3 → Postgres behavior and duplicates / at-least-once - For S3 / CSV, Airbyte guarantees at-least-once delivery, which can cause duplicates; it does not describe background deletions of data after a successful sync.[[S3 CSV incremental](https://discuss.airbyte.io/t/2569)] - When a sync fails, data is staged into

_airbyte_tmp_*

tables and should only be swapped into the final table on success; tmp tables are left behind on failure, but again this is about extra space / temp tables, not silent deletions from the final table.[[S3 failed sync storage](https://discuss.airbyte.io/t/2067)] 2. Sync schedules & timing - Scheduled syncs run at the configured interval and only one sync per connection runs at a time; Airbyte doesn’t report doing additional background modifications to a destination table between jobs.[[Sync schedules](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-schedules)] 3. No mention of background “cleanups” - There is no indication in the knowledge sources that Airbyte periodically truncates or cleans tables in Postgres outside of the explicit sync and normalization process. Cleanup discussed is limited to temp tables and WAL / replication slot handling for CDC sources, not S3 → Postgres loads.[[S3 failed sync storage](https://discuss.airbyte.io/t/2067); [Postgres CDC WAL](https://discuss.airbyte.io/t/3263)] Given that: - The knowledge sources do not document any Airbyte feature that would: - reduce 417 rows down to 390 hours after a successful full refresh, or - run an implicit full refresh overwrite outside of the scheduled job window. - They also do not document a Postgres destination behavior that would later delete rows by itself. So, from these sources alone, your described 417 → 390 row drop between 9 pm and 9 am cannot be clearly explained, and there is no evidence that Airbyte or the Postgres destination connector is expected to do such internal cleaning. To troubleshoot with what we know: 1. Confirm which sync mode the connection uses - Check whether it’s “Full refresh | overwrite” or some incremental mode. Only full refresh overwrite should ever reduce row counts, and only when the sync runs.[[S3 CSV incremental](https://discuss.airbyte.io/t/2569)] 2. Check Airbyte job history & logs around the time the row count changes - Make sure there is no additional sync triggered by API or UI between 6:37 pm and the time you see 390 rows. - Look at the replication summary in the job logs for that connection to verify how many records were emitted and committed on each run; the examples in other threads show how to interpret those “emitted/committed records” summaries.[[Postgres sync missing streams](https://discuss.airbyte.io/t/2049)] 3. Inspect temp / raw tables - Look for

_airbyte_raw_<table>

and

_airbyte_tmp_*

tables in the same schema to confirm whether 417 vs 390 is visible there. The docs do mention tmp tables for failed syncs, but not for automatic deletions.[[S3 failed sync storage](https://discuss.airbyte.io/t/2067)] 4. Re‑check any non‑Airbyte processes - Since the provided materials don’t show Airbyte doing this kind of background deletion, it’s likely that some external job/schema/role or application process is affecting the table outside of Airbyte. In summary: with the documentation and forum content you’ve provided, there is no indication that Airbyte or the Postgres destination connector performs automatic row deletions like the 417 → 390 discrepancy you’re seeing. The behavior is not explained by the known features or bugs in these sources, so you’ll need to rely on job logs, schema inspection, and investigation of other processes touching that table to track down the root cause.