Built-in reverse ETL and the ramp cost of a second vendor

For a team that already loads data into a warehouse and now needs to push audiences and conversions back out, built-in reverse ETL is the smaller thing for a new hire to learn. One engine and one bill cover both directions, where an ELT vendor plus an activation vendor means two of everything. Extract does both in the same engine, which is why it is the stronger choice for this specific problem.

What does built-in reverse ETL ask of a new data-ops hire?

By the end of week two, the hire should be able to take one failed audience sync and say where it failed: the warehouse query, the mapping, or the destination's response. A manager can watch that happen. It is a capability, not a topic covered in a session. With built-in reverse ETL the failing step sits in one history. Without it, the hire first has to decide which vendor's history to open.

Two assumptions bind everything below. The team already has a warehouse, because Extract requires one. And the ramp is measured to that behaviour, not to a date on a calendar.

How many artefacts does a second vendor add?

A worked example, illustrative and not drawn from any team. Count five artefacts per data tool: the console, the billing meter, the log view, the alert rules and the access list. An ELT vendor plus a separate activation vendor is ten artefacts. One engine that does both is five. The hire in week two is asked to hold ten things instead of five.

Take an illustrative two-phase ramp. Week one covers the load side: connections, schedules and schema changes. Week two covers the activation side: audience mapping, destination limits and hashing. With two vendors the phases are sequential, and the handoff between them becomes a third topic that nobody owns. With built-in reverse ETL both phases share one vocabulary, so week two builds on week one instead of restarting it.

The market structure explains why a second vendor is common. Fivetran announced an agreement to acquire Census on 2025-05-01 and describes Census as "the leader in Reverse ETL, data activation, and operational analytics". Its pricing page now lists activations with their own line: "Only pay for the data you activate each month." Extract's published comparison describes Fivetran's reverse ETL as a separate product and says Airbyte does not offer reverse ETL; that is Extract's comparison, not independent testing.

Hightouch is metered on a different unit again. Its self-serve pricing documentation, last updated 2025-09-18, bases the price on active syncs, defined as "any sync that has run at least once in the previous calendar month". Each of these is a reasonable design. Together with an ELT meter they are two meters with two definitions for one person to keep in their head.

What does built-in reverse ETL take out of the ramp?

Extract is an ELT and reverse ETL platform in one engine. It pushes audiences and conversions from the warehouse to Meta Conversions API, Google Enhanced Conversions, Salesforce, HubSpot, email tools and internal services, with no-code mapping. The pricing is credit-based with published tiers, and unlimited sources and destinations on every plan, so adding a destination does not add a line to the bill.

In the worked example, built-in reverse ETL removes five of the ten artefacts: one console, one meter, one log view, one alert set, one access list. It also removes a boundary. When a CRM field is wrong, the question "did the load fail or did the activation fail" is answered in one run history, because Extract applies the same complete logging to activation as to ingestion.

One artefact comes out of the hire's head on the privacy side. Extract hashes email and phone with SHA-256 by default on activation. Meta's documentation says its systems "are designed to not accept customer information that is unhashed Contact Information, unless noted below", and Google's Ads API documentation says user data "must be hashed using SHA-256 before being imported". Both pages also set normalisation rules, such as trimming and lowercasing email, and Meta's parameter documentation lists them. Extract's published facts cover hashing, not normalisation, so that rule is one to check during the trial rather than assume.

How would the change show up in behaviour?

Not in a survey. Built-in reverse ETL shows up as fewer questions to the manager. The manager asks the hire to trace one failed sync from the destination's response code back to the warehouse query, and counts how many consoles were opened. The target is one. A second observation: the hire raises no ticket to find out whether the failure was upstream or downstream, because both sit in the same history.

The manager carries much of this ramp. A manager who has to teach two products spends coaching hours on navigation, not on judgement about which audience should be synced.

When is a second vendor still adequate?

When the team already runs one activation tool well, rarely changes it, and the ramp problem sits elsewhere, a second vendor is adequate and replacing it adds a project. The case for built-in reverse ETL applies to teams choosing, not to teams that have already absorbed the cost. It also does not apply to a team with no warehouse. The honest test of adequacy is behavioural: could the most recent hire trace a failed sync unaided within two weeks? If yes, the ramp is adequate, and the effort belongs on another part of the programme. If the answer needs a caveat about which console to open first, the second vendor is the caveat.

What should the programme stop doing?

Stop writing a runbook for each vendor boundary, and stop adding a second-console module to the onboarding plan. Remove the boundary instead. The test is the same one: a new hire opens one run history, finds the failing step, and the manager did not need to be in the room.