Lately almost every architecture conversation I’m in bends toward the same question. Someone has a curated dataset in the warehouse (a risk score, a patient summary, a cleaned-up eligibility table) and they don’t want to look at it in a dashboard. They want it to do something: land where the work happens.
That is reverse ETL, and in healthcare it’s become one of the more interesting problems I work on, because most of the time you can’t buy your way out of it.
This is part one of a series on building reverse ETL natively on the modern data platform.
What Reverse ETL Is
Reverse ETL takes a curated data product out of the warehouse and delivers it to an operational system to drive a business process. If ingestion moves data into the warehouse to be modeled, reverse ETL moves the result back out to where it gets used. It’s the same three verbs:
- Extract the curated dataset from the gold layer.
- Transform it into the shape the target expects, usually from structured tables to whatever semi-structured payload the receiver speaks (a JSON body, an NDJSON file, a delimited flat file).
- Load it by actually sending it, over whichever transport the receiver supports.
That symmetry with ingestion is comforting, and, as we’ll see, a little misleading.
Where the Standard Definition Stops
Search “reverse ETL” and you’ll find a tidy consensus, defined by a class of tool: a managed connector platform that syncs warehouse tables into SaaS destinations like Salesforce or HubSpot. Pick a source table, map fields, set a schedule, and it handles the API calls, dedup, and retries. If your destination is a mainstream SaaS app, it’s genuinely the right answer.
Here’s the problem. In healthcare, nobody sells you the connector. There is no managed “Snowflake to Epic” sync, no drop-down for “push this to the state HIE,” no field-mapper that speaks HL7v2. The destinations are EHRs, interface engines, clearinghouses, and trading partners; they expect FHIR resources, pipe-delimited messages, X12 envelopes, and files dropped on an SFTP at 2 a.m. The managed-tool definition can’t reach them.
Defining It by Pattern, Not Tool
This series defines reverse ETL by the pattern, not the tool. What makes something reverse ETL is the intent of activating a curated data product to drive an operational process, not whether a vendor’s connector exists. The question stops being “which tool do I buy” and becomes “how do I build this natively, on the platform I already have,” almost always Snowflake.
A few boundaries, because this definition can blur into its neighbors:
- It is not ingestion in reverse. The verbs rhyme, but the failure modes don’t.
- It is not a replacement for an interface engine. With HL7v2, the warehouse generates the message and hands off. It does not become your Rhapsody.
- It is not the managed-SaaS-connector product the category is usually sold as.
The Idea That Anchors the Series: A Spectrum of Coupling
Here’s why that symmetry misleads. The moment the warehouse becomes a source of writes, it inherits a problem it never had as a reporting endpoint: the thing on the other end has state, and your delivery changes it. A dashboard query that runs twice is harmless; a payload that lands twice can double-post a claim. That’s the real dividing line, and it’s why I organize the series along one axis: how tightly is the warehouse coupled to the receiver?
The Tight End: Synchronous and Conversational
You send one transaction, wait, and the receiver hands back an acknowledgment telling you exactly what happened, writing a single FHIR resource to an EHR by API, say. You know immediately whether it worked, but you’re bound to the receiver’s availability, rate limits, and notion of a valid request.
The Loose End: Asynchronous and Detached
You produce a payload, hand it off, and move on: a flat file dropped on an SFTP for a trading partner to pick up on their own schedule. The coupling is low, which buys resilience and scale, but you give up the instant acknowledgment. Proof the data landed comes later, out of band, if at all.
Neither end is better; they answer different constraints such as latency, volume, and whether the receiver even has an API. Every transport in this series is a point on that spectrum, and every later post (FHIR, HL7v2, EDI) is a payload format riding one of these choices. If you keep one idea from this article, keep this.
A Concrete Example, at the Tight End
Take the simplest useful case, deliberately at the tight end. The gold layer computes a credit limit per customer, recalculated nightly. It’s a genuine data product with one definition and one owner. Today it feeds a dashboard a finance analyst opens twice a month; when a limit changes in billing, someone reads it off and keys it in by hand. It’s a trustworthy number that never reaches the system that acts on it.
Reverse ETL closes that gap, and the three verbs map cleanly:
- Extract the limits that changed since last run, just the delta, because the receiver has state and you only want to touch what moved.
- Transform each row into the contract the billing API expects, almost never your table shape, but a JSON body with the receiver’s field names and identifiers.
- Load it by POSTing each payload to the billing endpoint and reading back what it says.
Why This Is the Tight End
That last verb is where the tight coupling shows itself. You send one account, wait, and get a synchronous answer: a 200 confirming the write, or a 422 saying the account is closed and the limit rejected. You know, per record, exactly what happened. The cost: if billing is down, you’re down; if it throttles, your run respects that.
Notice what has no equivalent in ingestion: the rerun. Naively re-POST and you risk applying the same change twice, causing a duplicate audit event or a wrong state. So even here the write must be idempotent: an UPSERT keyed on the account, or a token the receiver honors. And for a target like this there’s usually no off-the-shelf connector, and even where one exists, it won’t know your contract.
Reverse ETL Delivers Real Business Value
Three verbs and a coupling decision is the how. Here’s the why:
Most people don’t work in a dashboard. A dashboard is a destination a handful of analysts visit on purpose. Everyone else lives inside an operational system: the billing screen, the EHR, the CRM, the queue they work all day. An insight that requires stopping and switching tools is one most of them never see. Reverse ETL is how the same governed number reaches them.
It turns your data products into inputs for automation. A curated, governed dataset is exactly the trustworthy input an agentic or ML workflow wants. Not raw source data with its sharp edges, but a defined product with an owner and a contract. Reverse ETL is how it reaches the model or agent that acts on it.
One source of truth actually stays true. When the credit limit is computed once and pushed everywhere it’s needed, the number in billing is the number in the warehouse by construction. The alternative, where every system derives its own or a human re-keys it, is how you get three answers to one question.
It forces governance to the surface. When the warehouse only fed dashboards, its data never left a controlled boundary. Push it into other systems and you’re making deliberate choices about what leaves, to whom, and under what controls. The push becomes a natural chokepoint for consent, minimization, and audit, and the cleanest bridge into what you have to engineer for.
Cross-Cutting Concerns, and How to Mitigate Them
Here’s the bill for defining reverse ETL by the pattern instead of the tool. A managed connector handles much of this; build natively and you own all of it. None of it is exotic. These are table stakes for any system that changes another’s state, and regulated data just raises them.
Freshness and Frequency
The honest first question is how fresh the receiver actually needs the data, not how fresh you can make it. Overshooting is expensive, like hammering a rate-limited API every minute for a number that changes daily.
Mitigation: pin the cadence to a real business driver, prefer change-only delivery, and let latency drive the coupling choice.
Delivery Semantics and Idempotency
Writes have side effects, so the core question is whether the receiver might see the same payload twice. Some expose an idempotency key or honor an UPSERT; others give you a blind POST that creates a new record every time.
Mitigation: establish the receiver’s capabilities first, then design to them. Key on a stable business identifier where you can, and keep delivery state on your side where you can’t. Design for at-least-once delivery and make duplicates harmless, rather than chasing exactly-once across a boundary you don’t control.
Retry and Error Handling
Transient failures are normal: the receiver is briefly down, a token expired, one record in ten thousand is malformed. Without a plan, a single bad row can derail a whole run.
Mitigation: retry transient failures with backoff, and route persistent ones to a dead-letter table with enough context to diagnose. Good data flows; bad data is quarantined for a human.
Acknowledgment and Receipt
“The job succeeded” and “the receiver accepted the data” are different claims, and the gap between them is where reverse ETL quietly breaks. At the tight end, a synchronous ack tells you the write landed; at the loose end, you dropped a file and have to go find out.
Mitigation: capture whatever acknowledgment the transport offers, and for loose-coupled deliveries treat proof-of-receipt as a first-class step (a manifest, a control report), never assuming a landed file was processed.
Observability
You need to answer “did the thing that was supposed to leave actually leave, land, and get accepted” without logging into three systems. A run that reports success while silently delivering nothing erodes trust fastest.
Mitigation: instrument to prove delivery, not just completion. Count sent versus acknowledged, alert on the delta, and keep a queryable record that doubles as an audit trail.
Security and the Data Boundary
Every reverse ETL pipeline is data leaving your controlled environment, and often it’s regulated data. This is where “good practice” becomes “compliance obligation.”
Mitigation: lock down the egress path with allowlists, short-lived rotating secrets, encryption in transit, and egress logging. Scope every destination against the agreements that govern it, and let the single push-point enforce minimization, sending only the fields the use case needs.
Orchestration Ownership
Something has to decide when these jobs run, in what order, and who gets paged when they don’t. Get it wrong and you get either a tangle of warehouse tasks nobody can trace or a scheduler blind to whether your data is ready.
Mitigation: decide deliberately who owns the schedule, the warehouse itself or an external orchestrator, and make readiness a signal it can see, not a time it hopes is right.
The thread through all of these: once the warehouse can change another system’s state, correctness stops being “is the number right” and becomes “did the right number arrive, exactly once, provably, and only where it was allowed.”
The Two Ideas to Take Forward
First, reverse ETL is defined by intent, not by a tool: the moment you decide a curated data product should drive an operational process instead of sitting in a dashboard, you’re doing reverse ETL, connector or not. Second, everything about how you build it falls out of one axis, namely how tightly the warehouse is coupled to the receiver, and the concerns above hold wherever you land.
What’s left is the how. In part two of this series, I will walk through the four transport mechanisms that get a payload out of Snowflake, from the tight-coupled API push to the loose-coupled file drop, and turn the coupling spectrum into a decision table you can pick from.
Staring at a curated dataset trapped in a dashboard, trying to get it where the work happens? That’s the conversation we have every week. Reach out today; we’d be glad to think it through with you.
