Skip to main content
Docs
Feature Requests Onboarding Trust Center Status Page

Community

Connector Improvement: Improve Handling of Post-Sync Updates to Reduce Write-Back Delays

Answered
Ari Johannesson User

Hi Fivetran Support Team,

Our end users are experiencing issues related to eventual consistency in the current sync process. After a data sync has completed, operators may modify records in the source system. Because syncs are incremental, these post-sync updates are not captured until the monthly re-sync. As a result, write-backs for legitimate updates can be delayed by several weeks.

Impact

  • Changes made shortly after a sync are not reflected downstream in a timely manner

  • Write-backs can be delayed until the next monthly re-sync

  • This creates confusion for operators and undermines trust in data freshness

  • Manual workarounds or waiting periods are required to reconcile updates

Current Behavior

  • Daily syncs only capture strictly incremental changes

  • Updates made after a completed sync are excluded until the next monthly re-sync

Requested Enhancement
We would like to explore options to reduce this delay for recent updates, such as:

  • Supporting a configurable lookback window on daily syncs (e.g., reprocessing the last 24–48 hours of data), or

  • Providing an alternative mechanism to capture and propagate post-sync updates more quickly

 

Thank you,

Ari Johannesson

Please sign in to leave a comment.

Comments

3 comments

Date Votes
  • Official comment
    Sandeep Preetam Saila Fivetranner

    Hi Ari,


    The scenario you described—the delay in propagating post-sync updates until the next monthly re-sync—is consistent with how Fivetran handles incremental syncs and rollbacks, which are implemented based on the requirements and capabilities of each source connector. To better assess this enhancement, can you specify which connectors most urgently require a configurable rollback or lookback window for daily syncs? Understanding the affected connectors will help us evaluate feasibility and prioritize the work accordingly.


    Thanks,
    Sandeep

  • Ari Johannesson User

    Hi Sandeep,

     

    Thanks for your answer.

    This specifically refers to the Factbird connector.

     

    Thanks again,

    Ari

  • Unnikrishnan Nair Fivetranner

    Thanks for the details Ari.
    As Sandeep mentioned, these decisions and design are based on the APIs we have from the source, and choices that work best for all customers of the connector(especially for larger data volume). Having said that, we understand the data freshness issue - we are looking into what we can do to help. We will reach out for further inputs and will keep this thread updated as we pick this up for next steps.