# Reverse ETL Sync Modes


The Reverse ETL sources support three sync modes that define how RudderStack syncs data to the destinations.

- [Upsert mode](#upsert-mode)
- [Mirror mode](#mirror-mode)
- [Full sync mode](#full-sync-mode)

## Specify sync mode

You can configure the sync mode in the **Data Mapping** settings while connecting your Reverse ETL source to a destination.

{{< image src="images/data-pipelines/specify-sync-mode.webp" alt="Sync mode setting in RudderStack dashboard" >}}

## Supported sources

The following Reverse ETL sources support the sync modes listed above:

- [BigQuery]({{< ref "sources/reverse-etl/google-bigquery.md" >}})
- [Databricks]({{< ref "sources/reverse-etl/databricks.md" >}})
- [MySQL]({{< ref "sources/reverse-etl/mysql.md" >}})
- [PostgreSQL]({{< ref "sources/reverse-etl/postgresql.md" >}})
- [Redshift]({{< ref "sources/reverse-etl/amazon-redshift.md" >}})
- [Snowflake]({{< ref "sources/reverse-etl/snowflake.md" >}})
- [Trino]({{< ref "sources/reverse-etl/trino.md" >}})

## Upsert mode

In this mode, RudderStack inserts only the new records and updates to the existing records while syncing data to the destination.

RudderStack supports upsert mode for **all** destinations except the destinations that only support [mirror mode](#mirror-mode).

See [Sync behavior](#after-updating-mappings) for more information on how RudderStack syncs records after you update the source-destination mappings.

## Mirror mode

In this mode, RudderStack 'mirrors' the source by keeping the destination data the same as the source data. It performs insertion, updates, and deletion of records while syncing data to the destination.

{{< warning >}}
RudderStack does not support `track` event type for this mode.
{{< /warning >}}

RudderStack supports mirror mode for the following destinations:

{{< destinations mirrormode="yes" >}}

See [Sync behavior](#after-updating-mappings) for more information on how RudderStack syncs records after you update the source-destination mappings.

## Full sync mode

In this mode, RudderStack syncs **all** the records to the destination irrespective of whether they were updated or not. For example, if you have 10,000 records and only 2000 records were updated, RudderStack will still sync all the 10,000 records to the destination.

{{< warning >}}
Using the full sync mode will lead to a higher event usage as all the source records are sent to the destination in each sync.
{{< /warning >}}

Note that RudderStack supports the full sync mode for **all** destinations except the destinations that only support [mirror mode](#mirror-mode).

## Sync behavior

This section describes how RudderStack syncs data to the destinations in the below scenarios:

### First sync

When you sync data from the [Reverse ETL sources](#supported-sources) for the first time, RudderStack performs a full sync by default, **irrespective of the sync mode**. 

For the subsequent syncs, RudderStack will:

- Incrementally sync any new records since the last sync, in case of [Upsert](#upsert-mode) and [Mirror](#mirror-mode) modes.
- Continue to sync all the records to the destination in case of [Full sync mode](#full-sync-mode).

You can also force a full data sync at any point using the [Reset History and Full Sync]({{< ref "data-pipelines/reverse-etl/developer-guides/start-stop-syncs.md#start-and-stop-syncs" >}}) functionality.

{{< image src="images/retl-sources/reset-history-full-sync.webp" alt="Reset History and Full Sync option" >}}

### After updating mappings

{{< info >}}
This section is applicable only for [Upsert](#upsert-mode) and [Mirror](#mirror-mode) modes, as RudderStack syncs all the data to the destination in [Full sync mode](#full-sync-mode) regardless of whether mappings are updated or not.
{{< /info >}}

RudderStack determines whether to run a full sync depending on whether a source-destination field mapping is added/updated or removed.

- **If a mapping is removed**: RudderStack does not run a full sync. It continues to sync records incrementally as per the specified sync mode.
- **If a mapping is added or updated**: RudderStack runs a full sync.

#### Example

Consider the following source-destination mappings:

| Warehouse column | Destination field |
| :---| :----| 
| `email` | `email_id` |
| `first_name` | `fn` |
| `last_name` | `ln` |

If you remove the mapping for `last_name` (mapped to `ln` field in the destination), then RudderStack continues to sync the source records to the destination as per the specified sync mode. It ignores the records for the `last_name` column as the mapping was removed.

Now if you add a new mapping (highlighted in bold) as follows:

| Warehouse column | Destination field |
| :---| :----| 
| `email` | `email_id` |
| `first_name` | `fn` |
| `last_name` | `ln` |
| **`address`** | **`address`** | 

In this case, RudderStack runs a full sync as it has to update all the records as per the new mapping.

## FAQ

#### What happens to the records that have not been successfully sent to the destination in the previous sync?

In case of an unsuccessful delivery, RudderStack retries sending the events in the next sync.

<br />