Reverse ETL from a data warehouse to HubSpot: how it works and which route fits

Your warehouse knows which accounts are growing, which are late on an invoice and which have stopped logging in. Your sales team works in HubSpot and sees none of it. Reverse ETL closes that gap: it reads modelled rows out of the warehouse and writes them onto HubSpot records on a schedule.

The short answer on tooling is about shape. A packaged reverse ETL tool fits when each warehouse view maps to one HubSpot object, keyed on a unique property, with no rule that decides per record. Once the sync has to order its associations, write back into another system or apply a rule with a condition in it, a custom service fits better, and so do notebooks in a Microsoft Fabric lakehouse where one already runs.

What a warehouse holds

A warehouse holds copies of a business’s operational data, joined and queried in one place. Its tables fall into three groups.

Copies of source systems come first: the product database, billing, the ERP, support, and usually HubSpot itself. Loaders fill these. Fivetran is a common one, and its HubSpot connector copies HubSpot’s standard and custom objects into the warehouse and captures deletes. HubSpot’s own Snowflake Data Share does the same job for Snowflake, one way, out of HubSpot.

Modelled tables come next, built by the data team on top of the copies: one row per account with its usage over the last thirty days, a health score, a renewal date, lifetime revenue. These are the tables worth sending to HubSpot, because they answer the questions a seller asks. Everything else is history and working space that should never leave the warehouse.

What reverse ETL is, and where it sits

ETL moves data from operational systems into the warehouse. Reverse ETL runs the other way: it reads a modelled table or view and writes each row onto a record in an operational tool. In a stack it sits after the modelling and before the destination, as the picture above draws.

Three kinds of product fill that step for HubSpot. Packaged tools come first: Hightouch and Census both publish apps in the HubSpot App Marketplace. Census now sits inside Fivetran, which agreed to acquire it and offers its reverse ETL as Fivetran Activations. HubSpot’s own beta direct sync is the second: on Data Hub Enterprise it maps a Snowflake table or view onto contacts, companies, deals or custom objects, several at once with their associations, one way into HubSpot. The third is custom: a service, or notebooks in the warehouse itself, that we write and run.

How a sync into HubSpot is set up

Whatever the tool, setup runs in five steps, each settling something the next depends on.

1. Model one row per HubSpot record

Build a view with exactly one row for each record you want in HubSpot, carrying the key and only the columns the sync should write. A view that returns two rows for one account writes that account twice on every run.

2. Create a unique key property in HubSpot

Give each object a custom property that holds the warehouse identifier, and set it to require unique values. HubSpot allows up to ten unique ID properties per object, and its batch upsert matches on one of them. Email works as a key for a simple contact load and fails the first time two people share an address.

3. Map each column to a HubSpot property type

Every column needs a property of a compatible type: a number as plain digits with at most one decimal point, a date in ISO format or as a midnight UTC timestamp, a dropdown value that matches one of its options. Decide here which side owns each field. A property the sync writes should be read only for people in the CRM, or the sync and a salesperson overwrite each other on every run.

4. Choose the sync mode and the schedule

Create and update, update only, or create only. Update only is the safe choice when HubSpot, rather than the warehouse, should decide which records exist. The schedule follows the data: a view rebuilt nightly gains nothing from a sync that runs every fifteen minutes.

5. Run it against a sandbox, then reconcile

Point the first run at a HubSpot sandbox portal, compare row counts with record counts object by object, then run it a second time to prove nothing duplicates. Only then swap the credentials for production.

What breaks and how to prevent it

Keys that are not unique

A sync that matches on a property with duplicate values updates the wrong record, or fails. Hightouch’s HubSpot documentation warns that a non-unique match property causes duplicates and sync errors, and Fivetran’s Activations documentation says one significantly slows a sync. Enforce uniqueness on the HubSpot property, and test for it in the view.

Deletes nobody decided on

A row that disappears from a view is invisible to a sync that only reads what is there. Each tool offers a delete behaviour, from doing nothing to archiving the record. We leave it at do nothing and flag rows that leave the model for review, using archive only where the client wants it, because an automatic delete removes history a salesperson may still need.

HubSpot counts its 10 second burst limit per app, but every private app in an account shares one daily limit. Batch writes carry 100 records a call, so two million rows is at least 20,000 calls before a single association. Throttle a large run and schedule it outside working hours, or it spends the budget the portal’s other private apps depend on.

Values that do not fit the property

A number that arrives as text with a currency symbol, a date carrying a time, a status that is not one of the dropdown’s options: each one fails the batch or lands wrong. We map every column to a HubSpot type before the first run and send values that do not fit to a conflicts table rather than dropping them. On a senior living operator’s sync, that table is where a vocabulary change in the source surfaces first.

The backfill nobody planned

The first run of a new sync is a backfill, whether anyone planned one or not, and a view holding three years of history sends all of it at once. Treat that run as its own job: a dated window, outside business hours, reconciled before the incremental schedule starts. The same senior living sync brings a community’s whole history on the first run after that community is switched on.

When a packaged tool fits, and when it does not

The dividing line is shape rather than volume.

A packaged tool fits when the mapping is flat: each view maps straight onto its objects, keyed on a unique property, with no rule that varies per record. Health scores onto companies, product usage onto contacts, a renewal date onto a deal. That is what Hightouch and Census are built for, and a custom build for it is waste. On Data Hub Enterprise with Snowflake, try HubSpot’s beta direct sync before buying anything. In our effort bands a packaged sync with a stable mapping is 15 to 30 hours of setup.

A custom service fits when the sync has to do something a mapping cannot express. Associations across several tables or sources, written in order once both records exist. A deal stage set on creation and never again, so a salesperson’s move survives the next run. Timeline events that must never be sent twice, which needs a ledger. Or write-back, where a HubSpot form submission becomes a record in another system. The Snowflake page sizes that build at 70 to 150 hours.

Microsoft Fabric fits when the lakehouse already exists and the source is hard to reach. A senior living operator’s property management system speaks SOAP, with no webhooks and no changed-since feed. Notebooks in the operator’s own Fabric tenant read it every 6 hours, keep about 72,000 contacts and 45,000 deals in step, and write website leads back hourly through four safety gates. The build is described in full, and the Microsoft Fabric page covers the route: a 300 to 450 hour build, justified by the write-back and the source rather than by the warehouse.

Frequently asked questions

What does reverse ETL mean for a HubSpot portal?

It means reading modelled rows out of a data warehouse, such as Snowflake or a Microsoft Fabric lakehouse, and writing them onto HubSpot records on a schedule. Health scores, product usage, lifetime revenue and renewal dates land on companies, contacts and deals, where workflows, lists and reports can use them. ETL runs the opposite way, loading HubSpot and other systems into the warehouse.

Do we still need a reverse ETL tool if HubSpot syncs with Snowflake?

Possibly not. HubSpot’s beta Snowflake direct sync, on Data Hub Enterprise, maps one table or view onto one or more objects with their associations, up to 10 GB, 200 columns and 30 million records a run, one way into HubSpot on a schedule. It cannot filter rows, applies no per-record rules and writes nothing back out of HubSpot. Rules a warehouse view cannot express, and anything that has to travel back out of HubSpot, point to a custom service.

Which HubSpot property should a warehouse sync match records on?

A custom property that holds the warehouse’s own identifier and requires unique values, one on each object. HubSpot allows up to ten unique ID properties per object. Email looks convenient for contacts and produces duplicates or wrong merges the first time two people share an address. Matching on a property that is not unique also makes packaged tools slower, or makes them fail outright.

Does a warehouse sync delete HubSpot records when rows disappear?

Only if you configure it to. Hightouch can do nothing, clear fields, archive the record or, for contacts only, delete it permanently, and Census’s mirror behaviour archives records that leave the view. A sync that reads a modified timestamp never sees a deleted row at all. We leave deletes at do nothing and flag rows that leave the model for review, because an automatic delete in a CRM removes history that a salesperson may still need.

How much of HubSpot’s API budget does a warehouse sync use?

A private app gets 190 requests every 10 seconds on Professional and Enterprise, a marketplace app 110 in each installing account, and each batch call carries 100 records. The daily limit for private apps, 625,000 requests on Professional and 1,000,000 on Enterprise, is shared by every private app in the account. Runs of changed rows cost little. A full reload of every row is what exhausts the budget.

Reverse ETL from a data warehouse to HubSpot: how it works and which route fits

What a warehouse holds

What reverse ETL is, and where it sits