Document Full Refresh Overwrite Deduped (#43413)

docs/using-airbyte/core-concepts/sync-modes/README.md

@@ -12,13 +12,16 @@ A sync mode governs how Airbyte reads from a source and writes to a destination.
       - Method 2: Using change data capture. Only supported by some sources. See [CDC](../../../understanding-airbyte/cdc.md) for more info.
    2. Full Refresh: Read everything in the source.
 2. The second part of the sync mode name denotes how the destination connector writes data. This is not affected by how the source connector produced the data:
-   1. Overwrite: Overwrite by first deleting existing data in the destination.
+   1. Overwrite: Overwrite by replacing pre-existing data in the destination.
    2. Append: Write by adding data to existing tables in the destination.
-   3. Deduped History: Write by first adding data to existing tables in the destination to keep a history of changes. The final table is produced by de-duplicating the intermediate ones using a primary key.
+   3. Append Deduped: Write by first adding data to existing tables in the destination to keep a history of changes. The final table is 
+      produced by de-duplicating the intermediate ones using a primary key.
+   4. Overwrite Deduped: Overwrite by replacing pre-existing data in the destination and deduplicate the final data using a primary key.
 
 A sync mode is a combination of a source and destination mode together. The UI exposes the following options, whenever both source and destination connectors are capable to support it for the corresponding stream:
 
+- [Incremental Append](./incremental-append.md): Sync new records from stream and append data in destination.
 - [Incremental Append + Deduped](./incremental-append-deduped.md): Sync new records from stream and append data in destination, also provides a de-duplicated view mirroring the state of the stream in the source.
-- [Full Refresh Overwrite](./full-refresh-overwrite.md): Sync the whole stream and replace data in destination by overwriting it.
 - [Full Refresh Append](./full-refresh-append.md): Sync the whole stream and append data in destination.
-- [Incremental Append](./incremental-append.md): Sync new records from stream and append data in destination.
+- [Full Refresh Overwrite](./full-refresh-overwrite.md): Sync the whole stream and replace data in destination by overwriting it.
+- [Full Refresh Overwrite + Deduped](./full-refresh-overwrite-deduped.md): Sync the whole stream and replace data in destination by overwriting it, also de-duplicate the data.

docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md

@@ -0,0 +1,52 @@
+---
+products: all
+---
+
+# Full Refresh - Overwrite + Deduped
+
+## Overview
+
+The **Full Refresh** modes are the simplest methods that Airbyte uses to sync data, as they always retrieve all available information requested from the source, regardless of whether it has been synced before. This contrasts with [**Incremental sync**](./incremental-append.md), which does not sync data that has already been synced before.
+
+In the **Overwrite + Deduped** variant, new syncs will replace all data in the existing destination table and then pull the new data in. Therefore, data that has been removed from the source after an old sync will be deleted in the destination table. The **deduped** variant also means that the data in the final table will be unique per primary key \(unlike [Full Refresh Overwrite](./full-refresh-overwrite.md)\). This is determined by sorting the data using the cursor field and keeping only the latest de-duplicated data row.
+
+Full Refresh syncs may be [resumed](/understanding-airbyte/resumability) (to recover from transient errors for example), when this happens, duplicate may happen. If avoiding duplicate is a strong requirement, we recommend using **Overwrite + Deduped** over **Overwrite**. Bear in mind that deduplication incurs additional warehouse costs.
+
+## Example Behavior
+
+On the nth sync of a full refresh connection:
+
+## _Replace_ existing data with new data. The connection does not create any new tables.
+
+data in the destination _before_ the sync:
+
+| Languages |
+| :-------- |
+| Python    |
+| Java      |
+| Bash      |
+
+new data in the source:
+
+| Languages |
+| :-------- |
+| Python    |
+| Java      |
+| Ruby      |
+
+data in the destination _after_ the sync (note how the old value of "bash" is no longer present):
+
+| Languages |
+| :-------- |
+| Python    |
+| Java      |
+| Ruby      |
+
+## Destination-specific mechanism for full refresh
+
+The mechanism by which a destination connector accomplishes the full refresh will vary wildly from destination to destination. For our certified database and data warehouse destinations, we will be recreating the final table each sync. This allows us leave the previous sync's data viewable by writing to a "final-table-tmp" location as the sync is running, and at the end dropping the old "final" table, and renaming the new one into place. That said, this may not possible for all destinations, and we may need to erase the existing data at the start of each full-refresh sync.
+
+## Related information
+
+- [An overview of Airbyte’s replication modes](https://airbyte.com/blog/understanding-data-replication-modes).
+- [Explore Airbyte's full refresh data synchronization](https://airbyte.com/tutorials/full-data-synchronization).

docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite.md

@@ -42,7 +42,7 @@ data in the destination _after_ the sync (note how the old value of "bash" is no
 
 ## Destination-specific mechanism for full refresh
 
-The mechanism by which a destination connector acomplishes the full refresh will vary wildly from destination to destinaton. For our certified database and data warehouse destinations, we will be recreating the final table each sync. This allows us leave the previous sync's data viewable by writing to a "final-table-tmp" location as the sync is running, and at the end dropping the olf "final" table, and renaming the new one into place. That said, this may not possible for all destinations, and we may need to erase the existing data at the start of each full-refresh sync.
+The mechanism by which a destination connector accomplishes the full refresh will vary wildly from destination to destination. For our certified database and data warehouse destinations, we will be recreating the final table each sync. This allows us leave the previous sync's data viewable by writing to a "final-table-tmp" location as the sync is running, and at the end dropping the old "final" table, and renaming the new one into place. That said, this may not possible for all destinations, and we may need to erase the existing data at the start of each full-refresh sync.
 
 ## Related information