Snowflake is usually the system that already won. The warehouse is where finance, product and marketing finally agreed the numbers live, models are built on it, and the churn score everyone quotes in the QBR is a table in it. Then someone asks the obvious question: why is the CRM still the one place that score cannot be seen.
HubSpot's answer to that has changed recently, and most of what is written about it is out of date. For years the honest summary was that HubSpot could push data into Snowflake and nothing more. That is no longer true, and the current picture is more interesting: two separate one-way features with different price tags, different tier gates and different latency, which together look like a round trip and behave nothing like one. This guide covers what each of them actually does, where they stop, and how to tell when a warehouse-shaped problem has outgrown them. It sits alongside the broader guide to HubSpot integrations, focused on the connection that data teams ask about most.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Does HubSpot Integrate With Snowflake?
Yes, and the useful version of that answer is that it does so twice, through two products that do not know about each other.
The first is the HubSpot Snowflake Data Share, which makes your CRM data queryable inside Snowflake. It is built on Snowflake Secure Data Sharing, so nothing is copied and no pipeline runs. HubSpot maintains a database, your account is granted read access to it, and you query it with SQL like any other schema. It requires Data Hub Enterprise.
The second is Snowflake Direct Sync, currently in beta, which goes the other way. It reads a Snowflake table or view on a schedule and writes it into HubSpot contacts, companies, deals or custom objects. It requires Data Hub Enterprise and Smart CRM Enterprise together, and it consumes HubSpot credits.
Run both and data moves in each direction. That is not the same as a sync, and the gap between those two statements is where most of this guide lives.
What the HubSpot Snowflake Data Share Actually Gives You
This is the half that overdelivers, and it is worth knowing how much is in there before you evaluate anything else, because plenty of teams pay a vendor to replicate data they already have.
The share exposes a view per object type, named OBJECTS_<TYPE>. The coverage runs well past the core CRM:
| Group | What is included |
|---|---|
| Core CRM | Contacts, companies, deals, tickets, line items, quotes |
| Activity | Engagements, calls, tasks, conversations, form submissions |
| Marketing | Marketing emails, campaigns, landing pages, site pages, blog posts, forms |
| Advertising | Ad accounts, ad campaigns, ad groups, ads |
| Commercial | Invoices, sales documents, deal splits |
| Sales tooling | Sequences, templates |
| Custom objects | Exposed with a 2-unique_ID type identifier |
Around the objects you get the structural tables that make the objects usable: associations plus per-pair associations_x_to_y views and association_definitions, owners, teams and owner_team, pipelines and pipeline_stages, property_definitions, segments and segment_membership, per-event tables such as email opens and clicks, and a data_share_status view for monitoring the integration itself.
Properties arrive three ways: object_with_object_properties gives you every record with its properties as a JSON variant, object_properties gives you one row per property per record, and object_properties_history carries change history, truncated to the 45 most recent values for contacts and 20 for every other object.
That association coverage is the genuinely valuable part and the thing most alternatives get wrong. A contact table without the association graph is a mailing list. With associations and association_definitions you can reconstruct which deal a ticket belongs to, which company employs a contact, and which line items sit on which quote, which is what makes warehouse-side revenue modelling possible at all.
The Data Share is zero-copy. Nothing is replicated, no pipeline runs, and it consumes none of your HubSpot API quota. What it costs you is Snowflake compute, every time you query it.
The refresh detail that decides your architecture
There are two schemas and they are not interchangeable.
V2_DAILY updates once per day and is what HubSpot recommends querying directly. V2_LIVE updates every 15 minutes and is built on secure views.
The trap is that "live" is not uniformly live. Four V2_LIVE views update only daily: association_definitions, owners, pipelines and pipeline_stages. So a dashboard joining deals to their pipeline stage is 15 minutes fresh on one side of that join and up to 24 hours stale on the other, and nothing in the interface tells you which half you are looking at. Reps who moved a deal into a stage created this morning will not appear where they expect, and the bug report you get will be about the deal rather than the stage.
How to Connect HubSpot to Snowflake
Setup is short. It is the decisions either side of it that take time.
1. Confirm the tier before anything else
The Data Share requires Data Hub Enterprise, the product HubSpot renamed from Operations Hub Enterprise at INBOUND 2025. If you are on Professional there is no configuration that unlocks this, and the rest of the setup is moot. The Operations Hub guide covers what else sits behind that tier, which matters if you are pricing the upgrade against a build.
2. Collect two values from Snowflake
Run
SELECT CURRENT_REGION();to get your region, and note your account identifier inorg_name.account_nameformat. Getting the identifier format wrong is the most common reason the provisioning step fails silently.3. Install the Data Share from the App Marketplace
You need Super Admin or App Marketplace Access permissions in HubSpot. Supply the region and account identifier, and HubSpot provisions the share against your account.
4. Create a database from the share
Snowflake emails a data product notification once the share is available, and you create a database from it on your side. On a large portal the initial database creation takes a while, so schedule it rather than watching it.
5. Decide which schema each consumer reads
Point dashboards and scheduled models at
V2_DAILY, and reserveV2_LIVEfor the few things that genuinely need 15 minute freshness. Doing this deliberately at the start is the difference between a predictable Snowflake bill and a surprising one.
One environment note worth knowing. Snowflake direct shares normally require the provider and consumer accounts to sit in the same region and cloud, with cross-region sharing needing replication on the provider side. HubSpot supports all Snowflake regions across AWS, GCP and Azure, so this is handled for you, but it is the reason provisioning asks for your region rather than inferring it. If HIPAA is enabled on your HubSpot account, Snowflake Business Critical is required on yours.
Snowflake Direct Sync: Writing Data Back Into HubSpot
This is the newer half, it is in beta, and it is the reason the old "HubSpot to Snowflake is read-only" summary no longer holds.
Direct Sync reads a Snowflake table or view and writes it into HubSpot on a schedule you set. You pick the database, schema and table, choose the destination object, nominate a match key so records deduplicate against what is already there, map columns to properties, and set a frequency. Each run evaluates all the source data and updates only the records that changed.
It is a real capability and for the classic use case, pushing a model output such as a lead score or a propensity band onto a contact record, it does the job without anyone writing code.
What Direct Sync will not do
It writes four object types. Contacts, companies, deals and custom objects. Tickets, line items, quotes and engagements are readable through the Data Share and not writable through Direct Sync, so anything support-side or quote-side is a one-way street.
Filtering during syncs is not supported. You cannot say "only rows where region equals EMEA" in the sync configuration. You shape the data in Snowflake and point the sync at a view, which is fine as a discipline but means every change to sync scope is a warehouse change with its own review cycle.
The volume caps are firm. 10 GB per table or view, up to 30 million records per sync run, and a maximum of 200 columns. Wide denormalised tables hit the column cap sooner than teams expect, and a single wide feature table from a data science workflow can exceed it on its own.
It is scheduled, never real time. Syncs run on a frequency, so the gap between a value changing in Snowflake and appearing in HubSpot is bounded by that interval rather than by seconds. Any workflow that has to fire on the change itself is outside this.
It consumes credits and stacks two Enterprise tiers. Data Hub Enterprise and Smart CRM Enterprise together, plus HubSpot credits per run. The credit cost scales with how often you sync, which puts a meter on exactly the behaviour that makes the feature useful.
It is in beta. Which is not a criticism, but it is a fact worth weighing before a revenue-critical process depends on it, because beta features change shape and occasionally change pricing.
Where the Native Snowflake Integration Stops
Take the two features together and the limits stop being feature gaps and start being structural.
Two one-way pipes on independent schedules are not a sync. Nothing in the pair knows which system owns a field, so when both sides change the same property the last writer wins and neither side records that it happened.
The structural limits
There is no system of record. This is the big one. A real warehouse integration needs Snowflake to own the computed fields, scores, segments and model outputs, while HubSpot owns what reps and workflows edit, on the same record at the same time. Neither native feature expresses ownership, so the guarantee you get is whichever process ran most recently.
Nothing is event-driven. The Data Share refreshes on a 15 minute or daily cadence and Direct Sync runs on a schedule. Neither reacts to a change. A deal moving to closed won cannot trigger a warehouse process in seconds, and a score crossing a threshold in Snowflake cannot fire a HubSpot workflow until the next run.
The write side is narrower than the read side. You can read tickets, line items, quotes and engagements out of Snowflake and you cannot write any of them back. Support and quoting workflows that want warehouse-derived values on the record are outside the native path entirely.
The tier gate is the real price. Data Hub Enterprise for read, and Data Hub Enterprise plus Smart CRM Enterprise plus credits for write. For a team on Professional with a mature Snowflake practice, connecting the two natively means buying Enterprise for one capability, which is a subscription decision dressed as an integration decision.
Freshness is uneven inside the "live" schema. Four of the
V2_LIVEviews are daily. Any join that touches owners, pipelines, pipeline stages or association definitions inherits the slower half, and the result looks like a data quality problem rather than a refresh window.Property history is truncated. 45 values for contacts and 20 for everything else. That is enough for recent-state questions and not enough for the longitudinal analysis teams usually want a warehouse for, so lifecycle stage archaeology beyond those windows needs its own capture.
None of this makes either feature bad. The Data Share in particular is one of the better things HubSpot ships, and any team with Data Hub Enterprise should turn it on before considering alternatives. The point is that the pair covers analytics well and operations poorly, and most people asking about a HubSpot Snowflake integration want the operational half.
HubSpot Snowflake Integration: Data Share vs Reverse ETL vs Custom
Three ways to bridge the two, and as usual they are layers rather than rivals. If the middle term is unfamiliar, the guide to iPaaS covers the category, and the data mapping guide covers the field-level work that decides whether any of these succeed.
Zero-copy, no API quota consumed, maintained by HubSpot, and broader coverage than most paid replication. If you want HubSpot data in Snowflake for modelling and reporting, this is the answer and building anything else is waste. Turn it on first.
Direct Sync if you already hold both Enterprise tiers and the objects and volumes fit. A reverse ETL vendor if you need to write below Enterprise, want filtering in the tool rather than the warehouse, or need objects Direct Sync does not reach. Either way you are buying a scheduled batch, priced per run or per record.
Built against the HubSpot API and Snowflake directly, so a change fires in seconds rather than at the next interval, each field has an explicit owner, and tickets, line items and quotes are as reachable as contacts. Fixed cost, no credit meter, no Enterprise tier bought for one checkbox.
When to Build a Custom HubSpot Snowflake Integration
Almost nobody should start with a build. If you hold Data Hub Enterprise, the Data Share is free capability sitting in your subscription and the correct first move. The skill is recognising the moment the native pair stops being an integration and starts being a scheduled export.
Signs you have outgrown the native features
Something has to happen in seconds. A deal closing that must reach a provisioning system, a score crossing a threshold that must reroute an owner, a churn signal that must open a task today. Scheduled batch cannot express urgency, and shortening the interval is a cost lever rather than a fix.
The same field is edited on both sides. Once Snowflake computes a value that reps also touch, you need field-level ownership and a rule for what happens on conflict. Two independent one-way pipes will silently overwrite each other, and the symptom shows up weeks later as a number nobody trusts.
You need to write objects Direct Sync does not reach. Warehouse-derived values on tickets, line items or quotes are common asks and sit entirely outside the native write path. There is no configuration that extends it.
Enterprise costs more than the integration is worth. If the whole justification for Data Hub Enterprise plus Smart CRM Enterprise is moving a handful of computed fields in each direction, price that as a build. A one-time cost frequently beats two indefinite tier upgrades bought for one capability.
The volume or shape does not fit. Tables past 10 GB, wide feature tables past 200 columns, or sync scopes that change often enough that routing every change through a warehouse view has become the bottleneck.
Someone is reconciling the two by hand. The clearest signal is behavioural. When an analyst exports from HubSpot and queries Snowflake so they can compare, the pipes are already not trusted, and everything downstream is being done twice.
If several of those are true, the move is not replacing what works. Most teams that commission a build keep the Data Share exactly where it is for everything analytical, and add a custom layer for the operational writes: the event-driven paths, the fields that need an owner, and the objects the native write path cannot reach. That is the same pattern the HubSpot Salesforce integration guide describes for the other CRM and the HubSpot NetSuite integration guide describes on the ERP side.
One thing to know before you scope a build
The moment you leave the Data Share you are on HubSpot's API quota, and the numbers shape the architecture rather than decorating it. Professional accounts get 650,000 requests per day and Enterprise gets 1,000,000, both with a burst limit of 190 requests per 10 seconds. The CRM Search API is far tighter at 5 requests per second, and search is exactly what a warehouse integration leans on when it needs to find the HubSpot record matching a warehouse row.
That last detail is the one that separates people who have built this from people who have read about it. A naive design that searches HubSpot for each row in a Snowflake result set hits the search ceiling almost immediately. The workable shape is to carry HubSpot record IDs in the warehouse, which the Data Share gives you for free, and then write by ID in batches rather than searching per record. It is a fair question to ask anyone quoting you for the work.
What a Custom HubSpot Snowflake Integration Costs
The Data Share is included with a tier you may already own, so the cost conversation only opens on the operational half. When it does, the honest comparison is not build versus free. It is build versus the running cost of what you would otherwise buy: the second Enterprise tier, the credits per sync run, the reverse ETL seat priced per record, and the analyst hours spent reconciling two systems that were never told which one is right.
A custom integration is a one-time build plus ongoing maintenance, priced by scope. Writing three model outputs onto contacts is a smaller build than event-driven bidirectional flow across six object types with field-level ownership and a full historical backfill. The cost teams underestimate is never the build. It is maintenance, because warehouse schemas change every time an analyst ships a model, HubSpot properties change every time ops runs a cleanup, and an unowned pipe between them drifts until both sides are confidently wrong in different directions.
A custom build inverts the cost curve of a metered connector. You pay more up front and then nothing per sync run, so the more often you need the data to move, the more the economics favour building it properly.
That inversion is why we productised it. StackTie builds the connection against the HubSpot API and Snowflake directly for a fixed fee and maintains it on a flat monthly retainer, so the pipe carrying your model outputs into the CRM keeps working without a credit meter running or an owner going missing.
Data Share working fine and the writeback half still not there?
When something has to happen in seconds rather than at the next interval, when Snowflake and your reps both edit the same field, when you need to write tickets or line items, or when two Enterprise tiers cost more than the integration is worth, that is a build. StackTie builds custom HubSpot Snowflake integrations for a fixed fee and maintains them on a flat monthly retainer, alongside the Data Share you already have. Live in 14 days or your money back. Book a free audit and we'll map exactly which gaps are worth closing.
The Bottom Line
HubSpot integrates with Snowflake through two separate one-way features. The Data Share puts a genuinely broad slice of your CRM into the warehouse read-only, zero-copy, consuming no API quota, with a view per object plus associations, owners, pipelines, property definitions, segments and event tables. Snowflake Direct Sync, in beta, writes Snowflake tables back into contacts, companies, deals and custom objects on a schedule. If you hold Data Hub Enterprise, turn the Data Share on today. It is the best-value thing in this guide.
The pair stops in ways that are structural rather than incidental. Neither is event-driven, so nothing reacts in seconds. Neither expresses which system owns a field, so overlapping writes resolve by whichever ran last. The write side reaches four object types while the read side reaches thirty. Freshness is uneven inside the schema labelled live. And both sit behind Enterprise tiers, with the writeback half behind two of them plus credits. Keep the Data Share for everything analytical, which it does well, and build the operational layer it structurally cannot reach, because in a warehouse-centric business that layer is where the decisions actually get made.
