Reverse ETL Tools Compared

To diff, a tool has to remember what it sent. Where it keeps that memory decides how much access your warehouse team must grant, and where a copy of customer data ends up.

Hightouch offers 2 engines. The Basic engine computes the diff on Hightouch's infrastructure and needs only read access. The Lightning engine computes it inside your warehouse and needs read and write access. It keeps previously synced data in schemas it manages there: hightouch_planner and hightouch_audit. Its documentation recommends Lightning for syncs over 100 thousand rows, and says you can't move back to Basic once it's configured. Fivetran Activations mirrors that split: its Advanced Sync Engine caches state in a scratch schema in your warehouse, and its Basic engine stores state outside the warehouse when it has no write access.

Segment and RudderStack always keep state in your warehouse. Segment writes a records_<id> table of record IDs and checksums and a checkpoints_<id> table of timestamps in a managed schema it needs write access to. RudderStack keeps snapshots and failure tables in a _RUDDERSTACK schema that you create before connecting a source, and its cursor watermarks live there too. The trade is plain: a warehouse team that won't grant write access narrows the field to the engines with a read-only mode, and a privacy team that wants no customer rows outside the warehouse favours the in-warehouse engines.

Read the retention behaviour too. Hightouch's Lightning planner keeps only the 2 most recent plan tables, while its Changelog table in the audit schema keeps history, including any PII, until you remove it.

The diff matches a row in this run to the same row in the last run, so each model needs a column that identifies a row and never repeats. Hightouch calls it the primary key, Segment the Unique Identifier column, and both warn about duplicates. If the key repeats, 2 rows fight over 1 slot, and the destination flips between them on every run.

Pick the key the destination will also use to match the record, such as an email for a CRM contact or a customer ID stored in an external ID field. The same column then feeds the diff and the upsert. Keep the model narrow: select only the columns the destination consumes, because a wide model makes every unrelated column change look like a changed row.

A sync mode says what the tool may do to the destination. Insert only creates records. Update only touches records that already exist. Upsert creates or updates, matching on a key. Mirror also deletes, so the destination ends up matching the model. Vendors name and bundle these differently. Hightouch has upsert alongside insert and update modes, plus a separate delete behaviour setting. Fivetran Activations lists 6 modes, including Mirror and Append Only. RudderStack offers upsert and mirror. Segment lets you sync added and updated records, or deleted ones.

Delete behaviour is the setting to read slowly. Hightouch's choices when a row leaves the model are to do nothing, clear the mapped fields, or delete the destination record. Fivetran notes that Mirror compares against what Activations already sent, not against the destination's current contents, so a record someone edited by hand in the CRM is not repaired until the model changes it again.

Choose the narrowest mode that does the job. An enrichment of existing CRM contacts wants update only, so a bad query cannot create thousands of junk contacts. A suppression list for an ad platform wants mirror, because staying in the audience after leaving the model costs money.

Hightouch and Fivetran Activations are built around the sync itself. Both add an audience builder, called Customer Studio in Hightouch and Audience Hub in Fivetran Activations, which lets non-SQL users define segments over the models you maintain. Fivetran announced the Census acquisition on 1 May 2025, and Census's documentation now redirects to the Fivetran Activations pages, so the same product sits beside Fivetran's ingestion connectors in 1 vendor relationship.

Segment and RudderStack are customer data platforms that include a reverse ETL feature. If you already collect events with either one, the warehouse sync lives in the workspace and billing you already have. RudderStack bills per connection from a source to a destination, and its plans cap connections, so a source feeding 6 destinations counts as 6.

Polytomic splits the work differently. Its bulk syncs load untransformed data into data stores such as warehouses and databases, and its model syncs push a reusable model into business apps, so 1 tool covers both directions.

Some destinations pull for you. Braze Cloud Data Ingestion needs no separate vendor and reads up to 500 million rows per run from 5 platforms: Snowflake, Redshift, BigQuery, Databricks and Microsoft Fabric. It reaches Braze only, so a second destination needs a second solution.

No tool here fits every team. Match the constraint that binds first.

If ingestion already runs on Fivetran and your jobs trigger from dbt Cloud, Fivetran Activations keeps vendors to 1. Both it and Hightouch can trigger from dbt Cloud, so the trigger alone does not decide it. If marketers build their own audiences, compare Customer Studio and Audience Hub with RudderStack Audiences on who maintains the schema behind them, because the audience builder only shows fields the data team has exposed.

If events already flow through Segment or RudderStack, their reverse ETL features save a vendor and share permissions with the pipeline you run. Check connection or record based billing against your model sizes first. If your warehouse team grants read only access, only the Basic engines of Hightouch and Fivetran Activations fit; Segment and RudderStack need write access, so they are out unless that policy changes.

If everything goes to 1 destination, a native loader such as Braze Cloud Data Ingestion removes the sync vendor. If you need both warehouse loading and app syncing from 1 tool, look at Polytomic. If a model exceeds a vendor's per sync limit, read the limit: at 150,000,000 records per sync, 700,000,000 records take 5 syncs on Segment, so the first load is slower than the daily one.

If you need results in under a minute, none of these fits. Reverse ETL is batch, with schedules measured in minutes, so latency sensitive personalization belongs in an event pipeline that writes to the app directly.

A script that runs a query, upserts rows into 1 destination keyed on an external ID and runs from your orchestrator is a few days of work, and it's a sound choice when there is 1 destination and the model is a small table. You keep it in the code review and alerting you already use.

The cost shows up later. You own the state that makes the diff work, so a crash between sending rows and recording them either resends or drops changes. You own each API's rate limits and partial failures, the rule for deletes, and backfills after a mapping change. Each added destination multiplies that work, and the vendors sell exactly that surface. A practical test is to count destinations and models: when the count passes a handful, or when non-engineers need to change audiences, buy; when it stays at 1 or 2, a scheduled job with idempotent writes is enough. Orchestration tools schedule it, and the ETL vs ELT guide covers where the load into the warehouse fits.

Whichever route you take, treat the sync as a pipeline with an owner: watch freshness and failed-row counts the way you would for any load, as in data observability.

Interviewers rarely ask for a vendor. They ask a design question: the data science team has a churn score in the warehouse, so how does it reach Salesforce every morning? A strong answer names the model and its unique key, then explains the diff and where its state lives. It also settles delete behaviour and retries with idempotent writes, and says how you would notice a failed or partial sync.

That is the same reasoning the data engineering system design round tests, and ETL interview questions cover the load patterns underneath it. To practice the pipeline side, work through data pipeline interview questions and the data pipeline practice problems.