Reverse ETL: What It Is, How It Works and When to Skip It

On 1 May 2025, Fivetran signed an agreement to buy Census. Fivetran’s whole business was moving data from applications into warehouses. Census did the opposite: it moved data out of warehouses and back into applications. The company that built the road in bought the company that built the road out, and renamed the product Fivetran Activations.

That road out is called reverse ETL. The name is clumsy. The problem it solves is old.

What is reverse ETL?

Reverse ETL is the process of copying modeled data from a data warehouse, or another system of record, into the operational SaaS tools where teams act on it. A CRM, an email platform, a support desk, an ad network. The warehouse computes something useful, such as a customer’s lifetime value or a churn score. Reverse ETL writes that value onto the matching record in the tool a salesperson or marketer opens every morning.

dbt Labs defines it as “the process of getting your transformed data stored in your data warehouse to end business platforms, such as sales CRMs and ad platforms.” The same article notes two other names you will meet: operational analytics and data activation.

The word “reverse” only makes sense against the thing it reverses. Classic ETL (extract, transform, load) and its modern variant ELT pull raw data out of applications into a warehouse for analysis. Reverse ETL pushes the result of that analysis back out. One direction feeds reports. The other feeds action.

Think of a hospital lab. The lab runs the test, gets the result, and files it. If the result sits in the lab’s own filing cabinet, the doctor on the ward never sees it. Reverse ETL is the step that writes the result into the patient’s chart. Nobody admires that step. Without it, the test was pointless.

1. SaaS apps

   system of record

   Orders, contacts

   Events, tickets
   ETL / ELT
2. Warehouse

   SQL models

   Lifetime value

   Churn score
   reverse ETL
3. Action tools

   CRM, email, ads

   Fields on records

   Audiences

Why reverse ETL exists

For roughly a decade, the modern data stack got good at one direction. Fivetran, Stitch and Airbyte loaded raw records into Snowflake, BigQuery or Redshift. dbt turned those raw tables into clean models. Looker or Tableau drew charts on top.

Then the charts sat there. The account manager still opened Salesforce, not Looker. The lifecycle marketer still built segments in the email tool, not in SQL. The support agent still worked in Zendesk. Every useful number the data team produced lived one tab away from the person who needed it.

Teams patched the gap by hand. A weekly CSV export. A Python script on someone’s laptop that called the HubSpot API. A Zap that broke when a field was renamed. Reverse ETL tools turned that pile of one-off scripts into a product: one place to define what goes where, with logging and retries.

Fivetran’s own explainer names the three jobs people buy it for. Marketing teams target segments built from warehouse attributes. Sales teams see product usage and renewal dates on the CRM record. Customer success teams see health scores and adoption metrics in the tools they already use.

How reverse ETL works

Every reverse ETL tool on the market breaks the work into the same four parts. Segment’s documentation lists them as “Sources, Models, Destinations, and Mappings.” Fivetran’s explainer uses source, model, sync and destination. Same shape.

1. Source. The system the rows come from. For the warehouse-first tools, that is a cloud warehouse or lake. Segment’s setup guide names seven: Azure, BigQuery, Databricks, Db2, Postgres, Redshift and Snowflake.

2. Model. A query that returns exactly the rows and columns you want to send. Usually SQL or a dbt model, sometimes a visual filter builder. Each row needs a stable identifier. Segment calls it the Unique Identifier column and states that it “is used to detect new, updated, and deleted records.” Pick a column that changes, and every sync will look like a full rewrite.

3. Field map. The translation layer. Your column ltv_usd becomes the HubSpot contact property lifetime_value. Your email column becomes the match key the destination uses to find an existing record. This is where most of the judgment lives, and where most of the bugs start.

4. Sync. The scheduled job that compares, writes and records what happened. This is where the engineering is.

Change detection: send the delta, not the table

A naive sync would send every row on every run. With 2 million customers and an hourly schedule, that is 48 million API writes a day for perhaps a few thousand real changes. No destination API will tolerate that, and none should have to.

So the tools diff. Hightouch’s docs put it plainly: “Between runs, Hightouch uses change data capture to compare the current model results against the previous run and send only the rows that were added, changed, or removed.” Segment does the same thing through its identifier column. The first run is a backfill. Every run after that is a delta.

This is the single most important property of a reverse ETL tool. A sync that sends only what changed is cheap, fast and kind to rate limits. A sync that resends the whole table is a liability you will discover the day the destination starts returning 429s.

Write modes: insert, update, upsert, mirror

Destinations differ in what they allow, so each sync picks a write mode. Hightouch documents three primary ones. Insert adds new records only. Update changes existing records only. Upsert inserts the record if no match exists and updates it if one does. RudderStack adds a mirror behaviour, which keeps the destination identical to the source, including removals.

Upsert is the default for most contact and account syncs, because you rarely know in advance which customers the CRM already has. Mirror is the dangerous one. It deletes in the destination when a row drops out of your model. That is correct for an audience list. For a CRM, it is a disaster the Friday someone edits the model’s WHERE clause.

Rate limits and failure handling

Every SaaS API has a rate limit, and every bulk write eventually hits a record the destination refuses. A bad email format. A required field left empty. A picklist value that does not exist.

Hightouch’s retry documentation is a good reference for how this should work. A rejected record is retried within the same run with exponential backoff, five attempts by default. Requests rejected as invalid (400, 401, 403, 422) skip retries, because retrying a malformed request changes nothing. Rate-limited responses (429) get a larger retry budget. Across runs, Hightouch keeps “an index of every rejected record, keyed by its primary key,” and retries each one on later runs until it succeeds or leaves the model.

When a destination rejects a whole batch because of one bad row, Hightouch splits the batch in half, then in half again, until the bad record is isolated. The other rows go through. That detail separates a tool from a script.

1. Scheduled sync run

2. Run the model

   • Query returns current rows

3. Diff against last run

   • Added, changed, removed only

4. Map fields

   • Columns to destination properties

5. Write in batches

   • Insert, update or upsert

6. Retry rejects

   • Backoff in-run, index for next run

7. Run log: synced, rejected, retried

Schedules

Most syncs run on a timer. Segment offers fixed intervals from 15 minutes to 1 day, or specific times on chosen weekdays. Hightouch and RudderStack both accept cron expressions, and both can trigger a sync when an upstream job finishes, such as a dbt Cloud run or an Airflow DAG.

dbt’s playbook warns against chasing real time for its own sake: “Move with caution in the realm of ‘real-time’.” Every extra run is a warehouse query you pay for. An hourly sync on a model nobody reads more than once a day is money spent on nothing.

Reverse ETL vs ETL, ELT, iPaaS and CDP

The objection deserves a fair hearing, and it goes like this: “Reverse ETL is an API integration with a SQL query in front of it. We already have Zapier and a CDP. Why buy a third thing?” Half of that is right. It is an API integration with a query in front of it. The query is the point.

ETL and ELT move data into the warehouse. Reverse ETL moves it out. They are two halves of one loop, which is why Fivetran bought Census.

iPaaS tools like Zapier, Make or Workato react to events in one app and call another app’s API. They are excellent at “when a deal closes, post to Slack.” They are poor at “update 40,000 contacts with a score computed from three years of orders,” because they have no model, no diff and no notion of a table. If you are weighing those tools, our comparison of the 12 best integration platforms goes through them one by one.

Traditional CDPs collect events, build their own copy of each customer profile and send audiences from that copy. Reverse ETL uses your warehouse as the source for modeled fields. Implementations can retain change-detection state and rejected records; inspect their storage and retention behavior. The line has blurred: Hightouch now calls itself a composable CDP built on its reverse ETL engine, and Segment, a packaged CDP, ships reverse ETL as a feature.

The honest summary: reverse ETL is the right tool when the value you need to send is computed. A field that only exists after you join, aggregate or score data from several systems. If the field already exists in a source app, you need a copy, not a model.

Do you need reverse ETL?

1. Scores and segments already built in a warehouse

   Reverse ETL

   The value only exists after modeling; ship it to the tools.

2. One app event should trigger an action in another

   iPaaS (Zapier, Make, Workato)

   Event-driven, no table to diff.

3. Need event collection and profiles, no data team

   Packaged CDP

   It stores and resolves profiles for you.

4. Records live in Shopify, Stripe or HubSpot, no warehouse

   Direct app-to-app sync

   Same delta sync, without building a warehouse first.

When you don’t need it

Hightouch, Fivetran and RudderStack all rank on the first page of Google for “reverse etl”, and all three sell it. Their guides spend little time on when to skip it. Here is that list.

You don’t need reverse ETL if you have no warehouse and no plan for one. Building a warehouse to feed one CRM field is paying for a factory to bake one loaf.

You don’t need it if the destination already has a native integration that carries the field you want. A store that needs orders in its email tool should install the integration, not model orders in SQL.

You don’t need it if nobody will act on the data. A churn score synced to a CRM field that no workflow, view or person reads is a cost line with no return. dbt’s playbook makes the same point from the other side: its first step is understanding what the business owner expects, before writing any model.

The main reverse ETL tools

Four products dominate the “reverse etl tools” results. All four read from cloud warehouses, model in SQL, map fields and diff between runs. The differences are in what surrounds the sync.

Hightouch

Hightouch now describes itself as a “Customer Data & AI Platform for Marketers,” with reverse ETL as the engine underneath a composable CDP and an AI decisioning product. Its site says it “integrates with 300+ tools” across advertising, marketing automation, CRMs and customer success. Its sync and retry documentation is the most detailed public description of how a reverse ETL engine handles change capture, rejects and rate limits. It fits teams with a warehouse and a data team who want the marketing layer built on top.

Census (Fivetran Activations)

Census was an independent reverse ETL vendor until Fivetran announced the acquisition in May 2025 and now sells the product as Fivetran Activations. Fivetran calls the combination “one of the first platforms to cover both sides of data movement in one tool.” It fits teams already paying Fivetran for ingestion who want one vendor and one bill for both directions.

RudderStack Reverse ETL

RudderStack’s reverse ETL product page lists table syncs that turn warehouse rows into identify and track calls. It also lists custom SQL models, a visual field mapper, cron schedules, and orchestration from Apache Airflow or Dagster. It claims “over 200 business tools for activations.” It fits engineering-led teams who already collect events with RudderStack.

Twilio Segment Reverse ETL

Segment’s reverse ETL reads from the seven warehouses listed earlier and writes to Segment destinations such as Salesforce, Google Ads, Braze and Mixpanel. A special Segment Connections destination turns warehouse rows into Segment Spec calls, so warehouse data can flow through an existing Segment pipeline. It fits companies that already run Segment as their CDP and want the warehouse to feed it.

The cost of all four is the same, and it is not on the pricing page. You need a warehouse, someone to keep its models correct, and someone to own each sync when the destination changes its API. For a company with a data team, that cost is already paid. For a 12-person store, it is the whole project.

Reverse ETL without a warehouse: app-to-app sync

Here is the contradiction this category has not resolved. The mechanics of reverse ETL are general: a model, a field map, a diff, an upsert, a retry. The packaging assumes a warehouse. Most small and mid-size companies do not have one, and their systems of record are already SaaS apps.

A Shopify store’s orders live in Shopify. Its payments live in Stripe. Its sales pipeline lives in HubSpot. Its email and SMS run from Brevo. The data that needs to move is mostly not computed. It is copied, with a little translation: Shopify’s total_spent becomes a contact attribute, a Stripe subscription status becomes a billing attribute, and a HubSpot lifecycle stage becomes a segment. These values do not establish marketing permission; that needs a separate consent record.

For that shape, a warehouse adds a hop, a bill and a team, and returns nothing the sync needed. What the sync does need is everything the warehouse tools learned: incremental change detection, upserts keyed on a stable identifier, rate-limit backoff, a log of every rejected record. Those requirements are no smaller without a warehouse in the middle. App APIs are less forgiving than a warehouse query, if anything.

For a concrete app-to-app path, use the Shopify-to-Brevo guide. It starts with Brevo PushOwl and a consented customer plus one order. This native path is separate from Tajo’s connector availability. Do not add a warehouse merely to copy a field the app already owns.

Make the first useful result observable

Here is a design exercise, not a report of a live Tajo warehouse connector. A model produces customer_id, email and order_count. Before any write, define the matching record and create the destination attribute with its intended type.

Use one consented contact you control. Write the modeled count to the matching Brevo record, then read it back. Run the same model output again and expect no extra contact. Change the count and expect only the intended attribute to change. A later unsubscribe must remain effective even if an older model row still says the person subscribed.

Keep the model version, source ID, destination ID and outcome together. That small receipt distinguishes “the request was accepted” from “the intended record now has the intended value.” The Brevo API guide explains the destination write; it does not provide a warehouse connection or scheduler.

Reverse ETL with agents

The hard part of reverse ETL was never the HTTP call. It was the field map. Which column matches which property. Which identifier is stable. Which write mode will not delete half the CRM. That is judgment, and until recently it meant a data engineer reading two API references side by side for an afternoon.

The objection to handing that to an agent is fair, and it goes like this: “An agent will guess a field map, and a wrong guess in a system that writes to customer records is how you corrupt customer records.” Correct on the second half. Wrong on the first, if the agent’s output is a proposal rather than a write.

An agent can draft a field map from the source and destination schemas. Review the identity rule, blank-value behavior, write direction and consent authority before enabling execution. A useful proposal names the records it would change and the evidence that would count as success.

Tool access is only part of that system. A scheduler must still run the job, durable state must retain progress, and failure handling must distinguish safe retries from uncertain side effects. What an MCP server is explains that boundary with a read-only Tajo example.

Tajo is in early access. Confirm the actual source and destination available in your workspace and request a demonstrated test before activation. An integration guide or an MCP tool listing alone does not establish a production sync.

Picking your path

Start from the deliverable, not the category. Write down the one field you need in the one tool where someone will act on it. Then ask where that field is computed.

If it is computed in a warehouse, buy a reverse ETL tool, and choose by which vendor you already pay for. If it already exists in a source app, sync the apps directly and skip the warehouse. If nobody will act on the field, sync nothing.

The warehouse was never the goal. The field on the record was.