1. Last time of the sync is not to be confused with the time up to which data is loaded. Account for replication lag at the source. 2. The sync schedule storage - where will it be maintained? 3. Assuming the structure comparison will be done before every load - with an option to configure an approval for new field addition 4. Sync modes / 2 / deduped history - destination doesn’t support primary keys as far I understand. Unless you have staged the data and using it to join..I don’t understand. Will need you to explain what are we doing here. 5. CDC can’t capture deleted records — a very big caveat. Correct me if I’m wrong.

1. The “last time of the sync” refers to the most recent point in time at which the sync was run. It is important to consider the replication lag at the source when determining the sync schedule, as this can affect the completeness of the data that is transferred. 2. I believe the sync schedule is stored where airbyte-cron is stored but I could be wrong here. 3. The schema comparison, is the process of comparing the structure of the source and destination data stores to ensure that they are compatible. Could you clarify the question here? 4. Deduped history mode, is a sync mode in which only the most recent version of each record is transferred to the destination. This can be useful if you only need to keep track of the current state of your data, rather than a full history of all changes. To use this sync mode, it is not necessary to have primary keys on the destination, as long as you have a way to uniquely identify each record (such as a unique combination of fields). 5. You are correct that CDC (change data capture) cannot capture deleted records. CDC is a technique for tracking changes to data in a database, and it is only able to capture insert, update, and delete operations that have been applied to the database. If a record is deleted, it will no longer be present in the database and therefore cannot be captured by CDC.