Salesforce to Snowflake connector pricing: what zero copy, Sync Out and replication actually cost

How much does a Salesforce to Snowflake connector cost?

Budget for three bills, and the connector itself is usually the smallest of the three. You pay Snowflake for the warehouse time that lands and merges every refresh, you pay whichever pipeline vendor you pick on their own metric, and if you take the zero copy route you pay Salesforce for Data Cloud. Neither Snowflake nor Salesforce publishes a list price for the paths they recommend, so any specific dollar figure you read about this route came from someone's negotiated contract rather than from a price list.

That sounds evasive, so here is the useful version. The variable that actually moves your bill is not which vendor you sign with. It is how often you refresh and how much you land each time. A connector that reloads every object every hour when a fraction of a percent of records changed will cost several times what an incremental sync on a sensible schedule costs, on identical data, with the same vendor. Get the refresh strategy right and the vendor choice becomes a much smaller line item than the sales process suggests.

Do I need Salesforce Data Cloud for Snowflake zero copy?

Yes, and this is the fork that decides everything downstream. Zero copy sharing works through Salesforce Data Cloud, which is a separately licensed Salesforce product. Snowflake is explicit that its replication connector is "designed for users who do not use Salesforce Data Cloud and prefer a fully managed Snowflake Openflow connector", and that the zero copy integration "is recommended if you use Salesforce Data Cloud and require near real-time bidirectional integration".

Read that as a buying instruction rather than as documentation. If Data Cloud is already on your Salesforce contract, the cheapest and freshest option is the one you have already paid for, and running a replication pipeline alongside it is duplicated spend. If Data Cloud is not on your contract, do not let a vendor scope zero copy into a proposal without saying that a significant Salesforce purchase sits underneath it. This is the same shape of prerequisite chain that shows up on the database routes, where the free first-party option turns out to depend on somebody else's product or license.

What does the Openflow Salesforce connector actually bill you for?

Snowflake credits, metered as warehouse and service time, with no separate license fee for the connector. That makes the pricing model straightforward and the forecast harder, because your bill is a function of your own configuration rather than of a subscription tier. Three settings drive almost all of it.

The first is refresh frequency. Snowflake documents a configurable window of 1 minute to 24 hours. Every cycle is a Bulk API round trip plus the warehouse time to merge the result, and that cost repeats every cycle for the life of the pipeline. Picking one minute because it was available is one of the more expensive defaults available to you, and for most CRM reporting nobody can tell the difference between a fifteen minute and a one hour refresh.

The second is object scope. The connector discovers standard and custom objects you specify in its configuration, and it does not traverse relationships, so each object is a separate job. Syncing every object in a mature Salesforce org because it was easier than choosing is how a pipeline ends up costing more than the analytics it feeds.

The third is the one nobody counts. The connector "does not support hard deletes in Snowflake". Deleted records are flagged with isDeleted set to true and stay in the table until you run a delete query or a full refresh yourself. That is storage you pay for indefinitely, and it grows for as long as the pipeline runs. It also means every table scan reads rows that no longer exist upstream, so the cost lands on compute as well.

Is Fivetran cheaper than Snowflake Openflow for Salesforce?

It depends almost entirely on your record volume and on whether you are pricing the first month or the steady state. Fivetran meters monthly active rows, so the initial history load is the single largest month you will ever have, and it bills at that scale before anyone has validated the mapping. Openflow bills Snowflake credits, so the same load appears as warehouse time on a bill you already receive.

The honest comparison is not a per-row rate. It is what happens when things go wrong. On row or event metering, every reload while you correct the object scope or the formula field handling bills again at full scale. On credit metering, the same reload is warehouse time that shows up alongside everything else in your Snowflake bill, which is easier to absorb and considerably harder to attribute. Ask any vendor to price the initial load plus two reloads, because there will be reloads.

There is also a scenario where both are the wrong answer. If you need a small number of objects for a single analysis with no ongoing sync, a scheduled Bulk API export loaded with COPY INTO costs nothing beyond the Snowflake warehouse time, and no vendor on either side of this comparison will volunteer that.

Why is my Salesforce to Snowflake bill higher than expected?

Usually one of four reasons, and none of them is the vendor's rate card. The first is refresh frequency set far tighter than the business needs. The second is object scope that was never pruned after the initial build. The third is a full refresh strategy where an incremental one would do, which is the single most expensive configuration mistake on this route. The fourth is the accumulated weight of every record ever deleted in Salesforce, still sitting in your tables because the connector never removed them.

The fourth one is worth pausing on, because it is invisible in exactly the way that matters. Every sync reports success. Row counts go up, which reads as growth. Nothing in the pipeline will ever tell you that your opportunity table has drifted above what Salesforce actually holds. This is the kind of drift that only surfaces when someone notices a warehouse number disagreeing with a Salesforce report, which is why teams running pipelines they depend on tend to watch row counts and freshness against the source rather than trusting a green run log. Schedule the cleanup query against isDeleted on day one and the problem never starts.

What hidden costs should I budget for?

Three, and they are all engineering time rather than vendor invoices.

Rejoining your objects is the largest. The connector does not traverse object relationships, so the joins between Account, Opportunity and Contact that Salesforce reports gave you for free become warehouse models that somebody writes, owns and maintains. Budget the modelling layer as part of the project rather than as a follow-up nobody scoped.

Formula fields are the second, and they surprise people. Snowflake does not copy formula values. It reads the expression from Salesforce metadata, translates it into Snowflake SQL, and serves the result through a generated view. Where a formula uses something it cannot translate, the column returns NULL and the reason is left in a column comment. Rollup summary fields, VLOOKUP, REGEX and the $User global variable are all on the unsupported list, and on most mature orgs that covers at least one field somebody reports revenue from. Rebuilding those in the warehouse is real work.

The third is the second Salesforce org. Snowflake states you "cannot consolidate data from multiple Salesforce instances into a single database in Snowflake". If your company grew by acquisition and consolidated reporting is the business case, the first-party connector cannot do the job, and discovering that during implementation rather than evaluation turns a configuration decision into a re-platform.

How do I keep the cost down without losing freshness?

Set the refresh frequency from the business requirement rather than from the minimum the tool allows, and set it per object rather than globally. Opportunity and Account may genuinely warrant a fifteen minute cycle. A custom configuration object that changes twice a quarter does not need the same treatment, and the cost of pretending otherwise compounds every cycle for years.

Prune the object list to what is actually queried. Run the pipeline for a month, look at which tables anything downstream touched, and switch off the rest. It is the cheapest optimization available and almost nobody does it, because switching something off feels riskier than leaving it running.

Then schedule the delete cleanup so you stop paying to store records that no longer exist. Between those three, most teams find the bill drops without anyone noticing a change in the data they use. If you want the full comparison of routes and vendors rather than just the cost model, that is on Salesforce to Snowflake integration tools, and the implementation walkthrough is in sync Salesforce to Snowflake.

Does the same cost model apply to other sources?

Partly, and the differences are instructive. Snowflake's database connectors read a change log rather than polling an API, so refresh frequency is not the same cost dial. What carries across is the pattern of a prerequisite that decides the project before any feature comparison: a Data Cloud license here, a binlog setting the host will not let you change on the MySQL to Snowflake route, and a separate license on the Oracle one.

The other constant is that the vendor's rate card is rarely what decides your bill. On every route we have priced, the configuration decisions made in the first fortnight matter more than the logo on the invoice. For the wider category and the people cost that dominates larger programs, see data migration tools and what a data migration really costs.