Snowflake to Salesforce: the connector, integration and zero copy options for syncing warehouse data

How do I connect Snowflake to Salesforce?

Pick the path by what has to exist at the end. If the answer is "a number on the Account record", you need something that writes through the Salesforce API: a reverse ETL or sync tool, an iPaaS flow, or your own Bulk API job. If the answer is "a segment in Data Cloud built from warehouse data", zero copy federation is the cheaper and cleaner route because nothing moves. If the answer is "our analysts want Salesforce data in Snowflake", that is the opposite direction and Data Cloud can share out to Snowflake natively.

Five realistic options, and what each one actually leaves behind:

Five ways to connect Snowflake to Salesforce, by direction, what lands, latency and trade-off

Option	Direction	What lands	Latency	The trade-off
Reverse ETL or sync tool	Snowflake to Salesforce records	Real Salesforce objects and fields	Minutes to hourly, on a schedule	The default answer. Writes through the Salesforce API, so normal validation rules and automation apply
Data Cloud zero copy federation	Snowflake into Data Cloud	Data Cloud data lake objects, not records	Query time, no copy	Requires Salesforce Data Cloud. Great for segmentation, does not populate an Account field
Data Cloud zero copy sharing	Data Cloud out to Snowflake	A Snowflake share	Near real time	The other direction. Useful when analysts want Salesforce data in the warehouse
MuleSoft or an iPaaS	Either	Salesforce objects	Depends on the flow	Justified when the sync is one step inside a larger business process with approvals
Custom Bulk API job	Snowflake to Salesforce	Salesforce objects	Whatever you schedule	Cheapest to start, and you own upsert matching, retries, rate limits and error handling forever

Most teams end up on the first row. It is the pattern the whole reverse ETL tools category exists to serve: query the warehouse, map the result columns onto destination fields, upsert on a key, and keep a log of what failed.

Is there a Snowflake to Salesforce connector?

Yes, several, and they are not interchangeable. Dedicated reverse ETL vendors such as Hightouch and the former Census, now sold as Fivetran Activations after Fivetran acquired Census in 2025, treat Snowflake as a source and Salesforce as a destination object by object. Omnata runs as a Snowflake Native App, so the sync executes inside your own Snowflake account rather than in a vendor cloud, which matters when a security review says data must not leave. Adapters covers the same lane on a flat monthly price with visual field mapping, which suits ops and finance teams who want three dependable syncs and a predictable invoice rather than a platform.

What separates them in practice is depth per object, not the logo on a connector page. Two tools can both claim Salesforce and only one will write to a custom object with a required lookup relationship. Test the exact object you need during the trial.

How do I load data from Snowflake into Salesforce?

The mechanics are the same whoever does it. A query runs against a curated Snowflake table, the result columns get mapped onto Salesforce API field names, and the rows go through the Salesforce API as an upsert keyed on an external ID. Four details decide whether it holds up after the first week.

Use an external ID. Create a custom field on the target object, mark it External ID and Unique, and populate it with the stable key from your warehouse: a customer id, an account number, something that never changes. Upserting on that field means the second run updates rather than duplicates. Matching on email or company name works until somebody edits one.

Use Bulk API 2.0 above a few thousand rows. The REST API charges a call per record against a daily pool that every other integration in the org shares. Bulk API 2.0 takes a CSV, batches it for you, and processes asynchronously. It accepts up to 150,000,000 records per 24 hours for ingest jobs, with a single job payload capped at 150 MB of base64 encoded CSV, and Salesforce recommends staying under 100 MB of raw data to leave room for encoding overhead. Those figures were read from the Salesforce developer limits documentation on 12 August 2026.

Send only what changed. A full push of a large mart every hour wastes the API allocation and rewrites records that did not move, which also fires every workflow rule and flow attached to the object. That is how an innocent sync generates ten thousand emails. Track a watermark or a hash and push the delta.

Expect rejected records and plan for them. Salesforce rejects individual rows for reasons that have nothing to do with your data quality: a required field left empty, a picklist value that was deactivated last quarter, a record locked by an approval process, a validation rule someone added on Friday. You need per-record errors with the API response attached, a retry with backoff, and an alert that reaches a human.

What are the Salesforce API limits for loading data?

These are the numbers that shape the design. All were read from the Salesforce developer limits documentation on 12 August 2026, and the API call allocations are per org per rolling 24 hours, shared across every integration you run.

Salesforce API and Bulk API limits relevant to loading Snowflake data

Limit	Value	Why it matters here
Bulk API 2.0 records ingested per 24 hours	150,000,000	The ceiling almost nobody hits, but worth knowing before a first full load
Bulk API 2.0 job payload	150 MB of base64 encoded CSV	Salesforce recommends staying under 100 MB of raw CSV to allow for encoding overhead
Bulk API 1.0 records per batch	10,000	Only relevant on the older API, where you create batches yourself
Characters per record	400,000	A long text column out of Snowflake can breach this on its own
Characters per field	131,072	Snowflake VARCHAR defaults to 16,777,216 bytes, so truncation is a mapping decision
Daily API calls, Enterprise edition	100,000 plus 1,000 per Salesforce license	Shared with every other integration in the org, which is why REST row-by-row loading fails
Daily API calls, Unlimited edition	100,000 plus 5,000 per Salesforce license	More headroom, same shared-pool problem
Concurrent long-running requests	25 in production	Applies to requests lasting 20 seconds or longer

The allocation that actually bites is the daily API call pool, because it is shared. An Enterprise org gets 100,000 calls plus 1,000 per Salesforce license, and your sync is competing with the marketing tool, the CPQ package and whatever an admin wired up in Zapier. A REST-based load of 200,000 rows can eat the entire org allocation and take unrelated systems down with it. Bulk API 2.0 exists precisely so that a bulk load is not charged that way.

Snowflake to Salesforce data type mapping

Nine mappings cover most of what breaks. Snowflake defaults are generous and Salesforce fields are strict, so the failures cluster around size and time zones.

Snowflake data types mapped to Salesforce field types with the conversion care point

Snowflake type	Salesforce field	What to watch
NUMBER, default precision (38,0)	Number, Currency or Percent	Salesforce number fields cap at 18 digits total. A NUMBER(38,0) will not fit, so cast in the query
NUMBER(19,4) for money	Currency	Set the scale in Snowflake, not in Salesforce. Currency fields respect the org decimal setting
VARCHAR, default 16,777,216 bytes	Text (255) or Long Text Area	Text fields reject overlong values outright. Truncate deliberately in SQL so you choose what is lost
BOOLEAN	Checkbox	A NULL boolean is not false. Coalesce it, or the checkbox write fails or silently clears
TIMESTAMP_NTZ	Date/Time	No time zone is stored. Salesforce interprets in UTC, so an unconverted local timestamp shifts
TIMESTAMP_TZ	Date/Time	The safe choice. The offset survives the trip
DATE	Date	Clean, as long as the destination field really is Date and not Date/Time
VARIANT or OBJECT	Long Text Area	No native equivalent. Flatten to columns in the query, or serialize and accept it is not queryable
Any column name unquoted	API name, case sensitive	Snowflake folds unquoted identifiers to uppercase. Salesforce API names are not uppercase, so the mapping is never one to one

The identifier case row is the one that surprises people who have only worked on the ingestion side. Snowflake folds unquoted identifiers to uppercase, so a column created as health_score is stored as HEALTH_SCORE, while the Salesforce API name is Health_Score__c. Every mapping between the two is explicit. That is fine when a tool shows you the mapping visually and terrible when it is buried in a script nobody has opened since the person who wrote it left.

What is Snowflake to Salesforce zero copy?

Zero copy is Salesforce Data Cloud reading Snowflake data where it already lives instead of ingesting a copy. Salesforce markets the Snowflake side of this as Bring Your Own Lake, and it works in both directions: zero copy federation brings Snowflake data into Data Cloud for segmentation and analysis, and zero copy sharing publishes Data Cloud data back out to Snowflake. No pipeline runs and no rows are duplicated, which removes a whole class of freshness and storage problems.

The limitation to be clear about: zero copy federation gives Data Cloud access to your warehouse. It does not write values onto standard Salesforce objects. If the requirement is that an account executive sees a renewal risk score on the Account layout, zero copy alone does not get you there, and it also assumes you have licensed Data Cloud. For most mid market teams who simply want three warehouse-derived fields visible in the CRM, a scheduled sync is both cheaper and faster to stand up.

What does it cost to sync Snowflake to Salesforce?

Three separate meters, and people usually budget for one. There is the sync tool itself, which in this category is normally usage based and quote only, with Polytomic the exception at a published $500 a month entry price and Adapters flat from $49. There is Salesforce, where the cost is the API allocation you consume rather than an invoice line. And there is Snowflake compute, which is the one that gets forgotten: a sync that re-reads a large table every fifteen minutes wakes a warehouse every fifteen minutes.

Query an incremental view rather than a wide table, keep the sync interval honest about how fresh the business actually needs the data, and put a budget alert on the account before the first full backfill rather than after the invoice. Teams that get surprised by a warehouse bill are almost always surprised by a resync, not by steady state.

Which option should you choose?

If you need warehouse values on Salesforce records and you do not own Data Cloud, use a reverse ETL or scheduled sync tool. It is the shortest path, and the whole category is compared on the reverse ETL tools page. If you already run Data Cloud and the goal is segmentation, start with zero copy federation and only add a write-back sync for the specific fields that must appear on a record layout. If the sync is one step inside a larger approval-driven process, that is iPaaS work rather than data movement. And if you are still weighing a script against a purchase, the build versus buy calculation is unusually one sided here, because the hard part is not the query, it is upsert matching, rate limits, retries and error visibility against an API that changes three times a year.

For the opposite direction, loading Salesforce into the warehouse in the first place, see Salesforce to Snowflake and the guide on syncing Salesforce to Snowflake. If your CRM is HubSpot rather than Salesforce, the same mechanics apply to HubSpot and Snowflake. And if the field mapping itself is the part you are unsure about, the data mapping best practices guide covers the conventions that keep a mapping readable two years later.

Adapters syncs Snowflake into Salesforce on a schedule you choose, with visual field mapping, external ID upserts, retries and per-record logs, for a flat $49 to $399 a month with no row meter. Map a real pair in the tool at the top of this page to see the shape of it before signing up for anything.