What Is Reverse ETL?

The new reverse ETL platform launched. Customer health scores, computed in the warehouse overnight, now sync into Salesforce every morning. The sales team gets fresher data. The data team gets a thank-you note from the VP of Sales.

Two months later, the Salesforce admin opens a ticket: the sync is overwriting fields the sales team manually edits, the dedup logic is firing on records the sales team considers distinct, and the audit trail of who-changed-what has become unreliable. The thank-you note has not been retracted but has not been repeated either.

I have lived this in db2-pit-recovery-first work, where the practice of pushing analytical results back into transactional systems goes back to the late 1990s under names like operational data store and active data warehousing. The pattern was not new then and it is not new now. What is new is who is doing it (data engineers, not DBAs), where the destination lives (SaaS, not on-prem), and what kind of guardrails the destination has (looser, much looser).

Reverse ETL platforms compress decades of integration discipline into a setup wizard. The discipline that the wizard skips — idempotency, conflict resolution, audit, source-of-record clarity — is exactly the discipline that the destination's admin will discover, two months in, was the actual product.

Step One — The Wrong Assumption

"Reverse ETL is a new category. The old patterns do not apply."

"Reverse ETL is a new pattern for activating warehouse data into operational systems. The cloud data stack made it possible."

The first instinct treats reverse ETL as a category the cloud data stack invented. The framing is convenient because it positions the new tools as the natural answer to a new problem, with no prior art to compare against. The premise is that pushing data from a warehouse to an operational system is a recent capability that became feasible only when warehouses became cloud-native.

The premise is wrong on two counts. First, the pattern is decades old — operational data stores, active data warehouses, real-time data integration platforms, master data management write-back, the entire body of work behind the term "operational analytics" before it was renamed. Second, the new tools are not solving a new problem. They are solving the same problem with different defaults, different audiences, and different blast radius. The discipline that produced reliable bidirectional integration in the prior generation is exactly what the new tools either skip or rename.

Step Two — The Partial Signal

Three of four reverse-ETL flows look healthy. The fourth is what happens at the destination.

The mechanics of pushing data from a warehouse to a SaaS system are well understood. Pick the source table, pick the destination object, pick the field mapping, schedule the sync. Most reverse ETL platforms handle the mechanics cleanly. The data moves. The destination receives. The dashboard shows green. Three of four operational dimensions look healthy.

The fourth dimension is what happens at the destination when the sync arrives. The Salesforce admin who built the sales process around manual editing of certain fields discovers their edits being overwritten on the next sync. The customer success team that uses Salesforce as the source of truth for health scores discovers they are now downstream of the warehouse, with no clear path to override. The compliance team that needs an audit trail of changes discovers the audit trail now reads "system" for every overwritten field, which is operationally useless.

This is the partial signal. The pipe is healthy. The destination's social and operational fabric is what fails, and the dashboard does not measure that.

Step Three — The Failed Fix

You add conflict-resolution rules. The rules disagree with the sales team's actual workflow.

The team responds to the destination problem the way every integration team has always responded: add conflict-resolution rules. Last-write-wins is the default. That breaks first. Switch to source-wins, with manual-edit-protection on certain fields. That breaks differently — the fields the sales team thought were protected turn out not to be the fields they actually edit. Switch to destination-wins for those fields, source-wins for others. The rule set grows. Each rule is correct for the case it was added for. The aggregate behavior is unpredictable to the sales team, who now distrusts the sync.

Inside one quarter, the sales team has stopped trusting the synced fields. They start maintaining shadow data in fields the sync does not touch. The customer health score, which was the original justification for the project, is no longer the score the sales team acts on. They act on the shadow score. The reverse ETL platform is healthy. The use case it was bought to enable has migrated outside it.

The fix did not fix anything because it added technical sophistication to a problem that was social. The destination's workflow needed to be either accommodated or explicitly displaced; the rule set tried to do both at once and did neither.

Step Four — The Real Failure

It was never a sync problem. It was that the destination already had a source of truth, and reverse ETL implicitly tried to replace it.

The actual failure is in the assumption that reverse ETL is a one-way sync. It is presented as one-way. Operationally, it is a redefinition of the source of truth for the synced fields, from the destination system to the warehouse. The destination system — Salesforce, Marketo, Zendesk — was previously the source of truth for those fields. The reverse ETL pipeline tries to make the warehouse the source of truth for them. The destination's admin and users have not been consulted on this redefinition; they discover it when their edits stop persisting.

The clean version of reverse ETL acknowledges the redefinition explicitly. It is a source-of-record decision, not a sync configuration. The fields being synced should be designated as warehouse-owned, with the destination's edit capability either disabled or routed back to the warehouse. The fields that are destination-owned should not be in the sync. The hybrid — some fields warehouse-owned, some destination-owned, with the boundary documented and enforced — is the operationally honest configuration. The default sync, which redefines source of truth implicitly, is the configuration that produces the two-month-later ticket.

This is the lesson DB2 ops, MDM teams, and prior-generation integration engineers have learned in different forms. Bidirectional integration is a source-of-record problem. Pretending it is a sync problem produces sync configurations that work technically and fail socially.

Step Five — The Definition

Now the definition lands.

Reverse ETL is the practice of moving transformed data from an analytical warehouse into operational systems — CRMs, marketing platforms, support tools — to enable workflows in those systems to be driven by warehouse-computed values. Mechanically, it is a sync. Operationally, it is a redefinition of source of truth for the fields being synced, and the redefinition is the part most rollouts treat as implicit.

Most definitions describe reverse ETL as the new pattern for activating warehouse data. The description is accurate at the mechanical layer and silent on the source-of-record layer. The mechanical layer is the easy part. The source-of-record layer is where reverse ETL succeeds or fails as an operational program.

The discipline is making the source-of-record decision explicit, field by field, before the sync is configured. The sync configuration is downstream of the decision.

What Solix Enforces

Source-of-record at the boundary, not in the sync configuration.

What Solix's governance and archival platform enforces in this category is the source-of-record discipline that reverse ETL configurations skip. When data is captured into the governed environment, the source-of-record decision is bound at capture — this field is owned here, that field is owned there, the boundary is documented, the audit trail survives. Reverse ETL becomes a sync against an explicit source-of-record map, not a sync that implicitly redefines source of truth at runtime.

For SAP ECC, Oracle E-Business Suite, customer-master synchronization, and the long tail of bidirectional integrations between operational systems and analytical environments, the same model applies. The source-of-record decision is the operating-model question. The sync is the implementation. Programs that bind the two together produce the two-month-later ticket. Programs that separate them produce sync configurations that the destination's admin actually wants.

Three things to do this week

• List the fields your reverse-ETL pipelines write to the destination system. For each field, identify whether the destination system was previously the source of truth, and whether the destination's users have been informed that it no longer is. The list of fields where the answer to the second question is 'no' is the size of the source-of-record-redefinition problem your sync is implicitly creating.
• Make the source-of-record decision explicit, field by field, before the next sync configuration. For each synced field, the decision is: is this field warehouse-owned or destination-owned. Warehouse-owned means destination users cannot edit it (or their edits are routed back). Destination-owned means it should not be in the sync. The hybrid is documented, not implicit.
• Audit the destination admin's experience two months after launch. The technical sync metrics will look healthy. The destination admin's ticket queue is the actual signal. If the queue contains complaints about overwrites, dedup, or audit-trail clarity, the sync redefined source of truth without consent. The fix is upstream of the sync, in the source-of-record conversation that should have happened before configuration.

References

• Forrester Research — The Forrester Wave™: Data Governance Solutions, Q3 2025. Report ID RES184107
• Gartner Peer Insights, market category — Metadata Management Solutions. Reviewed 2026
• Gartner Peer Insights, market category — Augmented Data Quality Solutions. Reviewed 2026