Best HubSpot to Snowflake connector for RevOps teams: Data Share, Openflow and ELT compared

What is the best HubSpot to Snowflake connector?

For most RevOps teams it is the one their HubSpot tier allows, which sounds like a dodge until you look at how far the options diverge. The Data Share is a HubSpot-maintained database shared read-only into your Snowflake account. HubSpot documents two schemas, V2_LIVE "updated every 15 minutes" and V2_DAILY updated once a day, and inside them a view per object, association views in the form associations_contacts_to_deals, an event table per event type, lists and list memberships, owners, teams, pipelines and pipeline stages, and a property history view. That is a complete analytical model of the CRM, and the only thing it asks of you is a Snowflake account and the compute to query it.

The catch is one line at the top of HubSpot's page: available with Data Hub Enterprise. A Marketing Hub Professional portal, which describes a great many US mid-market companies funding a warehouse for the first time, cannot install it. That is not a feature gap you can work around. It is a licensing fact, and it should be the first thing you establish, before anyone opens a vendor comparison.

Which HubSpot to Snowflake connectors handle custom objects, deletes and history?

These are the three columns that decide the purchase, and the ones vendor pages skip. Custom objects, because that is where the business model usually lives. Deleted records, because a connector that never sees a deletion produces a table that only ever grows. Property history, because stage-duration and velocity analysis is frequently the reason the project was funded. Where a vendor does not document a behavior, the cell says so.

Does the Snowflake HubSpot connector land typed columns?

Partly, and the partly is the problem. Snowflake's Openflow Connector for HubSpot creates one table per object type you configure, and its documentation states that "Each table contains the complete JSON payload from the HubSpot API responses". It then creates a companion view per table, suffixed _VIEW, which "extract[s] commonly used fields from the JSON payload into individual columns". So a contacts table is a JSON column, and a CONTACTS_VIEW is a set of columns Snowflake chose.

For a RevOps team the words to notice are "commonly used". The properties that make a HubSpot portal worth warehousing are almost never the common ones. They are the custom lead score, the ICP fit flag, the product line, the renewal date, the fields somebody built for this business. Those are in the payload and, unless Snowflake considered them common, not in the view, and the documentation does not list what the view contains. The first job on this route, before any dashboard, is to diff the view columns against your property list. The full side-by-side against Snowflake's other connectors, where the same product family gives four different answers to what lands, is on HubSpot to Snowflake integration tools.

Two more lines from the same documentation matter to a buyer. The connector's Object Types parameter lists 32 supported values and none of them is a custom object. And it states nothing about deleted records at all, which for a timestamp-polling connector means a record HubSpot no longer returns is a record the warehouse keeps. Neither is a defect. Both are things to know in week one.

What does the HubSpot Snowflake data share cost?

HubSpot does not charge for the app. It charges for the tier the app requires, and its page states plainly that you bear all Snowflake costs. That reframes the comparison. The Data Share is free in the way a feature of an Enterprise subscription is free, and for a portal already on Data Hub Enterprise it is very hard to beat. For a portal that is not, the honest line item is the tier upgrade, placed next to the vendor fees of every other route, and HubSpot's pricing page is the only place to read that number on the day you buy.

The metered vendors bill on monthly active rows, events, credits or data volume, and on a HubSpot source the thing to watch is the event tables. Email opens, clicks, bounces and ad interactions dwarf the object tables in row count, and the initial load of a mature portal is the largest month you will ever have on any of those units. Snowflake's connector bills as Snowflake compute for the runtime and the warehouse, which is a floor rather than a rate. We charge a flat monthly fee on any HubSpot tier, and the cases where that is the wrong answer are listed on the comparison page rather than hidden.

Is HubSpot to Snowflake sync real time?

No route on this page is, and any vendor who says otherwise is describing a shorter interval. HubSpot exposes no change log to read, so every connector polls: the Data Share on HubSpot's 15 minute clock for V2_LIVE, with owners, pipelines, pipeline stages and association definitions refreshed only daily; Snowflake's connector on whatever duration you set, using "timestamps from previous calls"; the third parties on their own schedules against the same API. A deal that moves through three stages in an afternoon lands as its final stage on all of them.

That has a practical consequence HubSpot documents itself. If you copy from the share on a daily schedule, HubSpot recommends copying "data from the previous two days to account for delays". A one-day window is short by design and will never raise an error. Build the overlap in from the first run.

Which connector should a RevOps team actually pick?

Three cases cover most teams. If the portal is on Data Hub Enterprise, install the Data Share and spend the saved budget on the modeling layer. It exposes more of HubSpot than any third party, including custom objects and events, and the two things to design around are the 45 and 20 value history caps and the association rows that outlive deleted records. Subscribe to HubSpot's developer changelog the same day, because HubSpot states it "will introduce changes, some of them breaking changes" to the share and has already renamed columns twice.

If the portal is below that tier and your team will model JSON, Snowflake's connector is a defensible starting point, with the custom object gap and the undocumented delete behavior written into the requirements rather than discovered. If nobody owns the warehouse model, buy typed tables from a pipeline vendor and run the trial against your messiest custom object, not your contacts table. If what you actually want is marketing spend beside pipeline in one place, and not a warehouse at all, a unified marketing dashboard gets there in an afternoon and most of this article does not apply to you.

If you want typed columns on any HubSpot tier without a metered bill, declaring the properties you care about is a middle path that suits more RevOps teams than it gets credit for. Most warehouses use a small fraction of a portal's properties, and naming that fraction explicitly turns a new property from a silent gap into a change request. That is what we built, and the page above says where we are the wrong choice.

What to check before you sign

Ask for the destination DDL for one custom object you name, and for the column that will hold one custom property you name. A JSON column and a typed column are different deliverables sold under the same word. Ask what happens to a contact you delete in HubSpot, by column name and value, and note that the two first-party options already disagree: the share removes it from one view and not another, the connector says nothing. Ask how many historical values survive per property. And run a count reconciliation against HubSpot from the first sync, because on every route here a table that only grows looks exactly like a healthy pipeline from the run log.

The API limits that bound every one of these connectors, and the five failures that all surface as one 429, are on HubSpot API rate limits. The same tier-decides-the-route pattern on the other CRM, where a Data Cloud license plays the part Data Hub Enterprise plays here, is on Salesforce to Snowflake integration tools.