How do I connect HubSpot to Snowflake?

Three ways, and they are different products. HubSpot's Snowflake Data Share puts your CRM in Snowflake as a read-only shared database, refreshed every 15 minutes, but it needs Data Hub Enterprise. Snowflake's Openflow Connector for HubSpot polls the HubSpot API with a private app token and lands the JSON payload. Or a third-party pipeline extracts through the API and writes typed tables. Which one you can use is decided by your HubSpot tier before any feature comparison.

What is the HubSpot Snowflake data share?

A HubSpot-built integration that shares your CRM data into your Snowflake account without copying it. HubSpot maintains a database, Snowflake grants your account read access to it, and you query it with SQL. It exposes two schemas, V2_LIVE updated every 15 minutes and V2_DAILY updated daily, plus objects, associations, events, lists, owners, pipelines and property history. It requires HubSpot Data Hub Enterprise and you pay all Snowflake compute.

Is there a HubSpot to Snowflake connector from Snowflake?

Yes. The Openflow Connector for HubSpot is a Snowflake preview feature that authenticates with a HubSpot private app token, retrieves a configured list of object types on a schedule such as 30 minutes or 1 hour, and creates one table per object type. Snowflake states each table "contains the complete JSON payload from the HubSpot API responses", with a companion _VIEW that extracts commonly used fields. It is a payload landing, not a typed schema.

Does HubSpot integrate with Snowflake in both directions?

Yes, through two separate products that are easy to confuse. The Data Share moves HubSpot data into Snowflake. Snowflake Direct Sync, a HubSpot beta that also requires Data Hub Enterprise, moves data the other way, from a Snowflake table or view into contacts, companies, deals and custom objects, capped at 10 GB per table, 30 million records per run and 200 columns. Neither product does the other product's job.

How much does the HubSpot Snowflake integration cost?

HubSpot does not charge for the Data Share app itself, but it is only available on Data Hub Enterprise, which is the actual entry ticket, and HubSpot's page states you bear all Snowflake costs. Snowflake's Openflow connector bills as Snowflake compute for the runtime and the warehouse. Third-party pipelines meter rows, events or credits. The honest comparison is between billing units, not list prices, and this page refuses to print prices it cannot verify.

How often does the HubSpot Snowflake data sync refresh?

For the Data Share, the V2_LIVE schema is updated every 15 minutes with one exception HubSpot documents explicitly: association_definitions, owners, pipelines and pipeline_stages update only daily. V2_DAILY is updated once a day and is what HubSpot recommends for direct querying. For the Openflow connector, you set the schedule yourself as a duration. None of these routes is real time and no vendor should tell you otherwise.

Does the HubSpot Snowflake data share include custom objects?

Yes. HubSpot documents that custom objects are assigned an ID at creation in the form 2-unique_ID and appear alongside the standard objects, with association views between them. That is a real advantage over Snowflake's own connector, whose documented object type list runs to 32 standard types and does not mention custom objects at all. If custom objects carry your revenue model, that single row decides the route.

Does the HubSpot Snowflake integration keep property history?

Partly. The Data Share exposes an object_properties_history view, but HubSpot states it holds "the most recent 45 values" for contacts and "the most recent 20 values" for every other object. A deal whose amount changed 30 times keeps 20 of them. The Openflow connector documents no history at all. If you need every transition, land a full copy on a schedule and keep it yourself.

What happens to deleted records in the HubSpot Snowflake data share?

They disappear from one view and linger in another. HubSpot states the objects view "only returns existing records" and a deleted record "will be removed", while for the associations view "rows may be present in this database object even though the referenced records have been deleted". A join between the two is therefore not clean by default. The Openflow connector documents nothing about deletes at all.

Which is better for HubSpot data ingestion into Snowflake, the data share or a connector?

If you own Data Hub Enterprise, the Data Share is the strongest first-party option on this page: typed views, associations, custom objects, events and a 15 minute cadence with nothing to run. If you do not, Snowflake's connector lands a payload you will model yourself, and a third-party pipeline or a flat-priced mapping layer lands typed tables. The tier question comes first, then the schema question, then the vendor.

HubSpot to Snowflake Integration, Connector, Sync

Which HubSpot to Snowflake connector should you use?

One question decides it, and it is not a feature. If your portal is on Data Hub Enterprise, install HubSpot's Snowflake Data Share: it gives you typed views for every object including custom objects, association views, email and ad events, lists and property history, refreshed every 15 minutes, with nothing to run. If you are not on Data Hub Enterprise, that route does not exist for you at any price short of a tier change, and the choice is between Snowflake's Openflow connector, which lands a JSON payload you will model yourself and lists no custom objects, a third-party pipeline that meters rows or events, or a flat-priced mapping layer that lands the typed columns you declare. Settle the tier, then the schema, then the vendor.

One scoping note before anything else. If this is a one-time extract of a few objects for a single analysis, the cheapest correct answer on this page is an API export loaded with COPY INTO, and no vendor will tell you that. For the wider vendor landscape see HubSpot integration tools, and for the ongoing warehouse load pattern, Snowflake ETL tools.

Snowflake ships one connector per source, and the HubSpot one lands something none of the others do

Openflow is one product family with one connector per source. Put the HubSpot connector next to the Salesforce, PostgreSQL, MySQL, SQL Server and MongoDB connectors and they answer the same operational questions differently, without any page acknowledging the others. On the question that matters most to a buyer, what actually lands in the warehouse, the family now has four different answers. We read all six documentation sets on 15 September 2026. The last column is what we would ship.

What is at stake	What the docs say	Why it matters to a buyer	What we would ship
What actually lands	Snowflake states that for the HubSpot connector "Each table contains the complete JSON payload from the HubSpot API responses", and that each raw table gets a view with the suffix _VIEW which "extract[s] commonly used fields from the JSON payload into individual columns".	This is the fourth answer to one question inside one product family. The PostgreSQL, MySQL and SQL Server connectors land column for column. The Salesforce connector lands typed columns plus generated views. The MongoDB connector lands a two-column payload and nothing else. HubSpot sits in between: the payload plus a view of fields Snowflake considers common. Your custom properties are, by definition, not common. They are in the JSON and not in the view, and nothing tells you which.	Diff the _VIEW columns against your property list before anyone builds a dashboard
What detects a change	The HubSpot connector uses "timestamps from previous calls" and an optional Updated After filter, on a Data Ingestion Schedule expressed as "a valid time duration, such as 30 minutes or 1 hour".	Timestamp polling, the same mechanism as the Salesforce connector and unlike the database connectors, which read a log. A record changed twice between two runs lands once. Nothing that happens between runs is recorded, so a deal that moved through three stages in an afternoon shows only the last one. That is fine for a current-state dashboard and useless for velocity or stage-duration analysis.	Treat the tables as periodic snapshots, never as an audit trail
Whether deletes are seen at all	The HubSpot connector documentation does not mention deleted records, a delete marker column or removal. The Salesforce connector documents isDeleted. The database connectors document _SNOWFLAKE_DELETED.	A timestamp poll asks HubSpot for records updated after a moment in time. A record that no longer exists is not returned by that query, so the connector has no mechanism to learn it was deleted, and the documentation does not claim one. The row stays. Every run reports success while the contact count drifts above what HubSpot shows, and the drift reads as growth. HubSpot's own Data Share, by contrast, states deleted records are removed from the objects view.	Reconcile counts against HubSpot on a schedule from day one, and ask the vendor which column carries a delete
Custom objects	The connector's Object Types parameter lists 32 supported values, from Appointments to Users. Custom objects are not among them. HubSpot's Data Share documents custom objects as "2-unique_ID" with their own views and associations.	HubSpot portals that justify a warehouse project almost always carry custom objects, because that is where subscriptions, properties, vehicles, policies or whatever the business actually sells live. The first-party Snowflake connector does not list them. The first-party HubSpot share does. On this route the two vendors' free options are not interchangeable, and the difference is the object that holds your revenue.	List your custom objects before you shortlist; it removes one first-party option immediately
Associations	The HubSpot connector page does not mention associations. The Data Share exposes "associations_<source>_to_<destination>" views plus a combined associations view and association_definitions.	Almost every useful HubSpot question spans two objects: deals by company, contacts by deal, tickets by contact. In the payload landing, association data is whatever the HubSpot object API returned, which for most endpoints is nothing unless it was asked for. The join logic HubSpot reports give you for free becomes warehouse code somebody has to write and own.	Budget the association model as part of the project, not as a follow-up
One filter for every object	Snowflake documents that "When multiple object types are defined, filtering by 'Updated After' applies to all object types defined in the parameter context."	A backfill of deals from 2019 and contacts from 2024 is one flow with one date, or two flows. The database connectors in the same family have no such coupling, because they read a log rather than a search filter. Small, and the kind of small that costs a re-run of the largest object.	One flow per object family with a different history horizon
How fast the backfill can go	"The processors are designed to work on the primary node only with one thread." And: "The number of calls your private app can make is based on your account subscription."	The connector serializes on one thread against HubSpot's private app limits, which on Professional and Enterprise are 190 requests per 10 seconds and a daily allocation that is shared across the whole account. The initial load of a large portal is bounded by that ceiling, and every other private app on the portal is drawing from the same daily pool. Scaling out is not an option the documentation offers.	Size the first load against the daily account cap, not against the burst limit
What the free option requires of you	The Data Share requires "Data Hub Enterprise" and, for HIPAA-enabled portals, "a Snowflake Business Critical account", and HubSpot states you bear all Snowflake costs. The Openflow connector is a "Preview Feature" covered by the Snowflake Connector Terms and needs a private app token with the necessary scopes.	The prerequisite chain on the HubSpot side is a license tier, on the Snowflake side a preview status. Neither is a feature and both decide the architecture. A Marketing Hub Professional portal cannot use the Data Share at any price without changing tier, and a regulated US business on the Openflow route is running a preview feature in production, which its own governance may not permit. Both facts are one line on a documentation page.	Confirm the tier and the preview status in writing before the evaluation starts

None of this makes the documentation wrong and we would still start with it. It makes the point that a connector family is a set of separately built products rather than one consistent contract, even when one vendor owns all of them and the destination. The first row is the one to act on today, because a property that lives in a JSON column and not in a view is invisible until a number is missing from a board deck. The same comparison for the other SaaS source is on Salesforce to Snowflake integration tools, for the relational sources on Postgres to Snowflake migration tools, and for the source whose connector lands no schema at all, MongoDB to Snowflake migration tools.

The four mechanisms buyers keep confusing

Most confusion on this route comes from treating "HubSpot to Snowflake" as one thing. It is four different products with different owners, different bills and different failure modes, and one of them moves data in the opposite direction. Two require Data Hub Enterprise and two do not, which is the first fork in any evaluation.

Mechanism	Owner	How it moves data	Who it is for	What to watch
HubSpot Snowflake Data Share	HubSpot	HubSpot maintains a database in Snowflake and shares it read-only into your account; V2_LIVE every 15 minutes, V2_DAILY daily	Portals on Data Hub Enterprise that want typed views, associations, custom objects and events with nothing to run	Requires Data Hub Enterprise. Property history capped at 45 values for contacts and 20 for other objects. HubSpot warns it will ship breaking changes.
Openflow Connector for HubSpot	Snowflake	Polls the HubSpot API with a private app token on a duration schedule, lands the complete JSON payload per object type plus a _VIEW of common fields	Snowflake teams without Data Hub Enterprise who will model the payload themselves	Preview feature. No documented delete handling, no custom objects in the type list, associations not mentioned, one thread.
Snowflake Direct Sync	HubSpot	Maps a Snowflake table or view to HubSpot properties and syncs on a schedule, one way from Snowflake into HubSpot	Teams activating warehouse models inside the CRM, which is the opposite direction	Beta, Data Hub Enterprise, 10 GB per table or view, 30 million records per run, 200 columns. Frequently mistaken for an extract.
Third-party ELT	Fivetran, Airbyte, Matillion, Portable and others	Extracts through the HubSpot API and loads typed tables to Snowflake with the vendor's own schema handling	Teams with several sources who want one pipeline vendor, or who lack Data Hub Enterprise and want typed tables	Every vendor handles deletes, custom objects and property history differently. Ask all three questions by name rather than accepting "we sync HubSpot".

HubSpot to Snowflake connectors and integration tools compared

Pricing models rather than price tags, because every vendor here except us either quotes or meters, and any figure printed on this page would be stale within a quarter. HubSpot publishes its tier prices on a pricing page we will not paraphrase, and Snowflake bills its connector as compute, so this page names the billing unit instead of inventing a number. Where a tool is wrong for a job, the last column says so.

Tool	Approach	Best for	Billing unit	What to watch
HubSpot Snowflake Data Share	Read-only shared database maintained by HubSpot inside Snowflake	Data Hub Enterprise portals wanting the fullest first-party model	Included with Data Hub Enterprise; you pay all Snowflake compute	The tier is the price. A portal below Enterprise cannot use it, and HubSpot states it will introduce breaking changes to the share, so subscribe to the changelog.
Snowflake Openflow	First-party managed connector polling the HubSpot API on a schedule	Snowflake teams who will model the JSON payload themselves	Snowflake credits, metered as runtime and warehouse time	Preview status, a payload landing with a partial view, no documented delete handling and no custom objects in its type list.
Fivetran	Fully managed ELT with schema drift handling	Teams who want zero pipeline maintenance across many sources	Monthly active rows	The initial history load is the largest active-row month you will ever have, and HubSpot event tables inflate row counts fast.
Airbyte	Open source connector framework, self-hosted or cloud	Engineering teams who prefer to own and patch the pipeline	Free self-hosted, capacity-based in cloud	Self-hosting moves the cost to your on-call rota, and the HubSpot rate limits are yours to pace against.
Matillion	Load plus in-warehouse transformation	Teams wanting the modeling layer and the pipeline from one vendor	Credit-based consumption	The transformation layer is the product. If you only need CRM objects landed, you are paying for a great deal you will not switch on.
Stitch	Managed replication built on the Singer specification	Straightforward object replication on a predictable budget	By rows loaded per month	A simpler product, which is the point. Less control over the schema and less help when HubSpot renames a table.
Hevo Data	Managed no-code pipelines with in-flight transformation	Smaller teams wanting a managed pipeline without enterprise pricing	By events loaded per month	Event metering and HubSpot email event tables are a bad combination during the first load.
Estuary Flow	Streaming pipelines with a persistent change log	Low latency across several sources without operating Kafka	By data volume and connector	HubSpot itself is polled through an API, so the lowest latency link in your chain will not be this one.
Portable	Managed long-tail connectors on a flat plan	Teams with several niche SaaS sources alongside HubSpot	Flat plan by connector count	Built for breadth of sources rather than depth on any one. Confirm custom object and association handling for HubSpot specifically.
Rivery	Managed ELT with reverse ETL and orchestration	Teams that want both directions from one vendor	Credit-based consumption	Credits abstract the row count, which makes the first backfill hard to forecast until it has run once.
API export plus COPY INTO	Scheduled API extract to files, staged, loaded with COPY INTO	A one-time analysis or a few objects on a slow cadence	Free, beyond the Snowflake warehouse time to load	Cheapest option here by a wide margin. You own the incremental logic, the deletes, the 10,000-result search cap and the retries.
Adapters	Field-level mapping you set once, then scheduled incremental sync	Teams below Data Hub Enterprise who want typed tables and a flat bill	Flat $49 a month, not metered by rows	We are not a shared database, we do not do sub-minute streaming, and we do not do in-warehouse modeling.

Six facts worth knowing before you sign anything

Data Hub Enterprise

The only HubSpot subscription on which the Snowflake Data Share is available. This is the entry ticket, and a portal on a lower tier cannot install it at any price.

HubSpot knowledge base, Connect HubSpot and Snowflake Data Share, read 15 September 2026

15 min

The V2_LIVE refresh cadence of the Data Share, except that owners, pipelines, pipeline stages and association definitions refresh only daily. V2_DAILY is what HubSpot recommends querying directly.

HubSpot knowledge base, Query HubSpot data in Snowflake, read 15 September 2026

Complete JSON payload

What Snowflake's Openflow Connector for HubSpot lands per object type, plus a _VIEW that extracts commonly used fields. The fields it considers common are not listed.

Snowflake documentation, Set up the Openflow Connector for HubSpot, read 15 September 2026

45 and 20

How many historical values the Data Share keeps per property: 45 for contacts, 20 for every other object. The most-edited records lose the most history.

HubSpot knowledge base, Query HubSpot data in Snowflake, read 15 September 2026

1 thread

Snowflake states the HubSpot connector processors "work on the primary node only with one thread", against private app limits that are shared across the whole HubSpot account.

Snowflake documentation, About Openflow Connector for HubSpot, read 15 September 2026

30M, 10 GB, 200

Records per run, data per table or view, and columns for Snowflake Direct Sync, the HubSpot beta that moves data the other way, from Snowflake into HubSpot. Not an extract, and often mistaken for one.

HubSpot knowledge base, Sync Snowflake data to HubSpot, read 15 September 2026

Eight ways this pipeline goes wrong while every check stays green

A HubSpot pipeline rarely fails loudly. It succeeds, the run log is clean, the row count went up, and a number somewhere is wrong. These are the eight we would check for on any existing HubSpot to Snowflake pipeline before believing a single figure it produces. Five of them are documented behaviors of the first-party options.

The failure	What you see	What is actually happening
A custom property that never left the payload	The _VIEW has no column for the property your forecast depends on, and nobody noticed because the view had plenty of columns.	Snowflake states the views "extract commonly used fields from the JSON payload". Your custom properties are not common fields. They are present in the raw JSON column and absent from the view, and the connector never lists which fields it chose. A dashboard built on the view is built on Snowflake's idea of your CRM, not yours.
Contacts that never leave	Every run succeeds and the contact count in Snowflake drifts steadily above the count in HubSpot.	The Openflow connector polls for records updated after a timestamp. A deleted record is not returned by that query and the documentation describes no delete marker and no removal. HubSpot's Data Share removes deleted records from the objects view, so the two first-party options disagree about the same deletion.
Deals in a stage that does not exist yet	A pipeline stage created this morning has deals in it in V2_LIVE, and the join to pipeline_stages returns nothing for them.	HubSpot documents that V2_LIVE is updated every 15 minutes but that "association_definitions, owners, pipelines, and pipeline_stages" update daily. Two refresh clocks inside one schema. Until tomorrow the stage id resolves to nothing and a stage-level report silently drops those deals.
The nightly copy that missed a day	An ETL job that copies "records updated yesterday" out of the share is short by a few hundred rows every week.	HubSpot's own guidance for ETL against the share: "if your flow copies data daily, it's recommended to copy data from the previous two days to account for delays". Delays exist and are documented. A one-day window is wrong by design, and no run will ever fail because of it.
History that stops at 45	A lifecycle stage analysis works for most contacts and is wrong for the most engaged ones.	The object_properties_history view holds "the most recent 45 values" per contact property and "the most recent 20 values" for other objects. The records with the richest history are exactly the ones whose early values have been dropped. A deal amount edited 30 times has lost its first 10.
A join that resurrects the dead	A deals-by-company report shows companies that were merged or deleted months ago.	HubSpot states the objects view only returns existing records but that association rows "may be present in this database object even though the referenced records have been deleted". An inner join to objects hides them; a left join from associations shows them. Which one your analyst wrote decides the number.
The column that was renamed under you	A query that ran for a year fails one morning with a column not found error, or worse, keeps running against a column that is no longer maintained.	HubSpot states: "As we evolve the data share, we will introduce changes, some of them breaking changes", and has done so: timestamp became updatedat, occuredat became OCCURREDAT. When a table is renamed, the old one lives on for a 90 day notice period and then goes. The changelog is the only warning you get.
A backfill that starves every other integration	The warehouse load runs fine for three days and the sales team's enrichment tool starts returning errors.	HubSpot's daily private app allocation is per account, not per app, and the Openflow connector runs on one thread against it. A large initial load consumes the shared daily pool, and the first thing to fail is whichever other integration hits the cap next. Nothing on the warehouse side reports a problem, because the warehouse side had none.

Six steps that decide whether this project works

Step 1

Find out your HubSpot tier before you read a vendor page

The Data Share is the strongest first-party route on this page and it is available on Data Hub Enterprise only. Ten minutes with whoever owns the HubSpot contract tells you whether that route exists for you. If it does, evaluate it first, because typed views, associations, custom objects, events and property history with nothing to operate is hard for any vendor to beat. If it does not, the shortlist is Snowflake's connector, a third-party pipeline or a mapping layer, and the tier upgrade is a line item to compare against all three.

Step 2

List your custom objects and your custom properties

Two lists, both short to produce and both decisive. Custom objects are absent from the Openflow connector's documented type list and present in the Data Share. Custom properties are in the connector's JSON payload but not necessarily in its _VIEW, because the view extracts fields Snowflake considers common. If either list carries your revenue model, and in most portals that fund a warehouse it does, you now know which first-party option is out.

Step 3

Decide what a deleted contact means to you

HubSpot's share removes deleted records from the objects view and leaves association rows behind. Snowflake's connector documents no delete behavior at all. A third-party tool will do something, and you need to know what by column name. Decide whether your warehouse should mirror HubSpot or keep history, write that decision down, and make every downstream model filter the same way. Making no decision means the second option happens by accident.

Step 4

Pick the refresh clock and design around it

V2_LIVE every 15 minutes, V2_DAILY once a day, the connector on whatever duration you set. None is real time. If you copy from the share on a schedule, follow HubSpot's own advice and copy the previous two days rather than one. If you need every stage transition rather than the current stage, no polling route gives it to you at any interval, and you should say so in the requirements rather than discover it in the first velocity report.

Step 5

Size the first load against the account-wide daily cap

Every private app on the portal draws from one daily allocation. A connector running on one thread through a large initial load will consume it, and the first failure will appear in a different integration. Schedule the backfill for a weekend, split it by object type with different history horizons, and tell the owners of the other integrations before it starts. The full limit set is on the HubSpot API rate limits guide linked below.

Step 6

Reconcile on values, never on row counts

Per object, compare the record count against HubSpot with deleted records excluded, the SUM of every amount field, MIN and MAX of every date, and a count grouped by pipeline stage or lifecycle stage. Then diff the columns you are actually querying against the property list. Row counts reconcile perfectly on a load that silently kept every deleted contact and never surfaced a single custom property.

Why US teams fund this project

Attribution that HubSpot reports cannot compute

The most common reason this gets funded. Multi-touch attribution across contacts, deals, email events and ad interactions needs SQL against the whole funnel, and the share exposes all four families as tables.

Joining CRM to product and billing data

The warehouse already holds Stripe, the application database or NetSuite, and HubSpot is the last source that cannot be compared against the rest of the business. Revenue retention needs all of them in one place.

Reporting on custom objects

Subscriptions, properties, policies, vehicles: whatever the business actually sells usually lives in a custom object, and that is the object one of the two first-party options does not list. Worth naming as a requirement in week one.

Retaining history HubSpot does not keep

Property history in the share is capped at 45 or 20 values. Teams that need every transition land a full copy on a schedule and keep it, which turns the polling limitation from a trap into a design choice.

Feeding lead scoring and forecasting models

Data science needs the whole contact and deal history in one queryable place. A timestamp-polled snapshot supports current-state models well and stage-duration models poorly, and the requirement should say which one it is.

Activating warehouse segments back into HubSpot

The return trip. That is Snowflake Direct Sync or a reverse ETL tool, not anything else on this page, and it is listed here because half the "HubSpot to Snowflake" evaluations we see turn out to be this one.

Five jobs where you should not pick us

A comparison page that never says the competition wins is an advert. These are the cases where we are the wrong answer and something on the list above is the right one.

A Data Hub Enterprise portal that wants the fullest first-party model with nothing to run. Install the Data Share. It exposes more of HubSpot than we do and there is nothing to operate.
A genuine one-time extract of a few objects for a single analysis. Use the API and COPY INTO. It is free and it costs less than we do.
Sub-minute latency into Snowflake. No route on this page delivers it, because HubSpot is polled through an API, and we are not the exception.
Moving warehouse segments into the HubSpot UI. That is Snowflake Direct Sync or a reverse ETL product, and it runs the other direction from everything here.
Heavy in-warehouse modeling as well as the pipeline. Land the data with us if you like, but the transformation layer belongs in dbt or Matillion.

Four questions to ask any vendor on this list

What happens to a contact I delete in HubSpot?

The fastest way to find out whether a vendor has run this route. HubSpot's share removes it from one view and not another. Snowflake's connector does not say. Ask whether the row is removed, flagged, or left untouched, ask which column carries the flag, and ask to see it in the destination DDL. "We keep them in sync" without a column name is not an answer.

Show me the columns for my custom object and my custom properties

Not "do you support custom objects", which every vendor answers yes. Ask for the destination table definition for a specific custom object you name, and for the column that will hold a specific custom property. The Openflow connector cannot show you the first and will show you a JSON column for the second. Whatever you buy, the DDL is the deliverable.

What HubSpot tier does this require, and what happens if we downgrade?

The Data Share requires Data Hub Enterprise and the Direct Sync beta does too. A pipeline tied to a tier is a pipeline whose cost includes that tier for as long as it runs. Ask the question of every route, including the free ones, and put the answer next to the vendor fee before comparing anything else.

Is this polling or change capture, and how do you say so?

Both get sold as sync. Polling compares a timestamp on a schedule and shows you current state; change capture reads a log and shows you every transition. HubSpot exposes no change log, so every route on this page is polling of one kind or another, and a vendor should say that rather than offer a shorter interval as if it changed the answer.

Related integration and warehouse guides

HubSpot is one source into Snowflake among several. These cover the wider HubSpot integration question, the API limits that bound every route on this page, the neighboring sources whose connectors this page is compared against, and the ongoing load pattern once the first sync is running.

Questions buyers ask about HubSpot to Snowflake integration

How do I connect HubSpot to Snowflake?: Three ways, and they are different products. HubSpot's Snowflake Data Share puts your CRM in Snowflake as a read-only shared database, refreshed every 15 minutes, but it needs Data Hub Enterprise. Snowflake's Openflow Connector for HubSpot polls the HubSpot API with a private app token and lands the JSON payload. Or a third-party pipeline extracts through the API and writes typed tables. Which one you can use is decided by your HubSpot tier before any feature comparison.
What is the HubSpot Snowflake data share?: A HubSpot-built integration that shares your CRM data into your Snowflake account without copying it. HubSpot maintains a database, Snowflake grants your account read access to it, and you query it with SQL. It exposes two schemas, V2_LIVE updated every 15 minutes and V2_DAILY updated daily, plus objects, associations, events, lists, owners, pipelines and property history. It requires HubSpot Data Hub Enterprise and you pay all Snowflake compute.
Is there a HubSpot to Snowflake connector from Snowflake?: Yes. The Openflow Connector for HubSpot is a Snowflake preview feature that authenticates with a HubSpot private app token, retrieves a configured list of object types on a schedule such as 30 minutes or 1 hour, and creates one table per object type. Snowflake states each table "contains the complete JSON payload from the HubSpot API responses", with a companion _VIEW that extracts commonly used fields. It is a payload landing, not a typed schema.
Does HubSpot integrate with Snowflake in both directions?: Yes, through two separate products that are easy to confuse. The Data Share moves HubSpot data into Snowflake. Snowflake Direct Sync, a HubSpot beta that also requires Data Hub Enterprise, moves data the other way, from a Snowflake table or view into contacts, companies, deals and custom objects, capped at 10 GB per table, 30 million records per run and 200 columns. Neither product does the other product's job.
How much does the HubSpot Snowflake integration cost?: HubSpot does not charge for the Data Share app itself, but it is only available on Data Hub Enterprise, which is the actual entry ticket, and HubSpot's page states you bear all Snowflake costs. Snowflake's Openflow connector bills as Snowflake compute for the runtime and the warehouse. Third-party pipelines meter rows, events or credits. The honest comparison is between billing units, not list prices, and this page refuses to print prices it cannot verify.
How often does the HubSpot Snowflake data sync refresh?: For the Data Share, the V2_LIVE schema is updated every 15 minutes with one exception HubSpot documents explicitly: association_definitions, owners, pipelines and pipeline_stages update only daily. V2_DAILY is updated once a day and is what HubSpot recommends for direct querying. For the Openflow connector, you set the schedule yourself as a duration. None of these routes is real time and no vendor should tell you otherwise.
Does the HubSpot Snowflake data share include custom objects?: Yes. HubSpot documents that custom objects are assigned an ID at creation in the form 2-unique_ID and appear alongside the standard objects, with association views between them. That is a real advantage over Snowflake's own connector, whose documented object type list runs to 32 standard types and does not mention custom objects at all. If custom objects carry your revenue model, that single row decides the route.
Does the HubSpot Snowflake integration keep property history?: Partly. The Data Share exposes an object_properties_history view, but HubSpot states it holds "the most recent 45 values" for contacts and "the most recent 20 values" for every other object. A deal whose amount changed 30 times keeps 20 of them. The Openflow connector documents no history at all. If you need every transition, land a full copy on a schedule and keep it yourself.
What happens to deleted records in the HubSpot Snowflake data share?: They disappear from one view and linger in another. HubSpot states the objects view "only returns existing records" and a deleted record "will be removed", while for the associations view "rows may be present in this database object even though the referenced records have been deleted". A join between the two is therefore not clean by default. The Openflow connector documents nothing about deletes at all.
Which is better for HubSpot data ingestion into Snowflake, the data share or a connector?: If you own Data Hub Enterprise, the Data Share is the strongest first-party option on this page: typed views, associations, custom objects, events and a 15 minute cadence with nothing to run. If you do not, Snowflake's connector lands a payload you will model yourself, and a third-party pipeline or a flat-priced mapping layer lands typed tables. The tier question comes first, then the schema question, then the vendor.

For the pair page that shows exactly how we map HubSpot objects onto Snowflake tables, see the HubSpot to Snowflake connector. For moving warehouse segments back into the CRM, see reverse ETL tools, and for the wider vendor landscape, the best data integration tools.

HubSpot to Snowflake integration tools compared: connector, data share and sync, and the license that decides it before any feature