Hello, We are using an Incremental | Append + Deduped sync mode in our connection, where the cursor field is based on a datetime column (e.g.,

updated_at

). We’ve noticed a potential issue with how Airbyte handles incremental syncs: If new records appear in the source with the same cursor value as the last recorded cursor (for example,

2025-10-20 09:42:11

), these rows are not picked up in the next sync. As far as we understand, this happens because Airbyte always applies the condition

cursor_field > last_cursor_value

, not

>=

, when filtering incremental data. This creates a risk of data loss if multiple rows share the same timestamp down to the same second or microsecond — which is common in high-frequency data sources. Could you please confirm: 1. Whether there is a way to configure or modify this behavior (e.g., use

>=

or apply a grace period/offset for the cursor)? 2. If not, is there any recommended best practice or workaround (such as cursor windowing or state rollback) to avoid missing records that share the same cursor value? Thank you for your help and clarification. Best regards!

New message text here

If we hypothetically changed the condition to:

WHERE cursor_field >= 'last_sync_max_cursor_field_value'

we’re wondering how this would behave during a single sync run where data is read in chunks/pages. Specifically: • If the number of rows with the same

cursor_field

value (

last_sync_max_cursor_field_value

) exceeds the configured chunk size (or page size), • would Airbyte re-read the same data repeatedly in subsequent chunks within the same sync? • How does Airbyte internally ensure consistency between chunks in such cases — is the cursor updated after every chunk, or only after the full sync finishes successfully? We want to better understand whether using a

>=

logic or any grace period could lead to duplicated or missed data within the same sync execution. Thanks for your help in clarifying this behavior.