There are four ways to get Salesforce data into BigQuery or Snowflake, and one of them does not move the data at all. Zero copy federation lets Data 360 query tables that stay in your warehouse, which inverts the usual problem: instead of getting Salesforce data out, you bring warehouse data in.
For the other three, the decision is set by how fresh the data has to be and who is going to own the pipeline in eighteen months.
The four options
| Bulk API extract | Change Data Capture | Managed connector | Zero copy federation | |
|---|---|---|---|---|
| Freshness | Batch, usually nightly | Near real time | Depends on the vendor | Live query |
| Who maintains it | You | You | The vendor | Salesforce and the warehouse |
| Handles schema change | You write it | You write it | Usually | Not applicable |
| Handles deletes | Poorly | Yes, explicitly | Usually | Not applicable |
| Cost shape | Engineering time | Engineering time | Per row or per connector | Platform licensing |
| Direction | Salesforce out | Salesforce out | Salesforce out | Warehouse in |
Option 1: Bulk API extract
The default first build. A scheduled job runs a query through Bulk API 2.0, writes CSV to cloud storage, and loads it into the warehouse.
It is the right answer more often than its reputation suggests. Bulk API 2.0 handles batching for you, allows 150 MB per job, and costs only a handful of API calls regardless of volume, since each HTTP request counts as one call. Query jobs are capped at 10,000 per 24 hour rolling window with 1 TB of results, which is far more than a nightly extract needs. Our Bulk API 2.0 guide covers the limits in full.
Two problems arrive later rather than immediately.
Deletes are invisible. A query returns records that exist. It says nothing about records that stopped existing, so a warehouse built on extracts slowly fills with rows Salesforce deleted months ago. Working around it means either full reloads, which get expensive, or querying the Recycle Bin, which only retains for a limited period.
Incremental extraction drifts. Filtering on SystemModstamp is the standard approach and it is correct, but any gap in a run window silently loses records, and nothing alerts you. The mitigation is overlapping windows plus periodic full reconciliation, which is more code than the original extract.
Option 2: Change Data Capture
Subscribe to change events and apply them to the warehouse as they arrive. Deletes are events like any other, so the hardest problem in option 1 disappears.
The constraint is the allocation. CDC delivery is capped at 25,000 events per 24 hours on Enterprise Edition and 50,000 on Performance and Unlimited, counted against subscriptions through the Pub/Sub API. A single ETL job or data load that touches 40,000 records exhausts that on its own, and the events you actually wanted get dropped behind it.
Retention is 72 hours. A consumer offline for a long weekend cannot replay what it missed, so a CDC pipeline needs a reconciliation query as its recovery path, not a replay. Our comparison of platform events and Change Data Capture covers the allocations and the add-on.
In practice the durable design is both: CDC for continuous change, plus a periodic full extract that repairs whatever the stream lost.
Option 3: a managed connector
Fivetran, Airbyte, Stitch and the warehouse vendors' own connectors all do this, and for a standard Salesforce to warehouse sync they are usually the right call.
What you are buying is not the extract, which is not hard. It is schema evolution, deletion handling, incremental state, retry logic and the API limit management that turns a working script into an unattended pipeline. That is the part that consumes an engineer's attention indefinitely.
What to check before signing:
- How deletes are handled. Soft delete flags, hard deletes, or neither.
- How custom fields and objects are picked up. Automatically, or on a schedule you trigger.
- How the pricing scales. Per row pricing on a high-churn object gets expensive in a way that is hard to forecast.
- Which API it uses. A connector making per-record REST calls will consume your API allocation in a way a Bulk API connector will not.
Option 4: zero copy federation
The newest option and the one that changes the question. Salesforce Data 360 can query tables that stay in Snowflake, BigQuery, Databricks or Redshift, without creating, persisting or hosting a copy.
Two modes exist: query federation and file federation. Sharing works in both directions, so insights generated inside Data 360, such as segmentation and identity resolution, can be read from Snowflake in real time without duplication.
Where this fits: when the warehouse is already your source of truth and what you actually want is Salesforce to see that data, not the other way round. Teams building a pipeline out of Salesforce into a warehouse that then feeds analytics back into Salesforce are building a loop that federation removes entirely.
Where it does not fit: when you need Salesforce data in the warehouse for reasons that have nothing to do with Salesforce, such as joining it to product telemetry in a model the CRM will never see.
Picking one
Three questions.
How fresh does it need to be? Daily is fine for most reporting, and a nightly Bulk API extract is the cheapest thing that works. Anything measured in minutes means CDC or a connector.
Who owns it in eighteen months? This is the question that should decide most builds and rarely does. A hand-built pipeline is a permanent claim on someone's attention, and the person who wrote it is usually not the person maintaining it.
Which direction is the data really going? If the honest answer is that the warehouse is the source of truth and Salesforce needs to see it, federation is a different and better shape than any extract.
Frequently Asked Questions
What is the best way to move Salesforce data to BigQuery?
For daily reporting, a scheduled Bulk API 2.0 extract into cloud storage and then into BigQuery is the cheapest approach that works. For near real time, Change Data Capture or a managed connector. If BigQuery is already your source of truth, zero copy federation into Data 360 avoids moving data at all.
Does Change Data Capture handle deletes?
Yes. Change Data Capture publishes events for record creation, update, delete and undelete, so deletions arrive as explicit events. This is its main advantage over a query-based extract, which returns only records that currently exist and never reports the ones that went away.
How much data can Bulk API 2.0 extract?
Query jobs are limited to 10,000 per 24 hour rolling window with 1 TB of total query results across that window. Ingest jobs share a 150 million record daily allocation with Bulk API 1.0. A nightly warehouse extract sits well inside these numbers.
What is zero copy in Salesforce?
A Data 360 capability that queries tables living in an external warehouse such as Snowflake, BigQuery, Databricks or Redshift without creating, persisting or hosting a copy inside Salesforce. It works through query federation and file federation, and sharing runs in both directions.
Should I build a Salesforce data pipeline or buy a connector?
The extract is easy, which is why teams build it. Schema evolution, deletes, incremental state, retries and API limit management are what a connector actually sells, and those are what consume engineering attention over time. Build only when your requirements are genuinely unusual.
Will a CDC pipeline hit Salesforce API limits?
Change Data Capture has its own delivery allocation rather than drawing on the REST API pool: 25,000 events per 24 hours on Enterprise Edition, 50,000 on Performance and Unlimited. A large data load can exhaust that on its own, so pair CDC with a periodic reconciliation extract.
Related Articles
- Salesforce Bulk API 2.0 guide
- Platform events vs Change Data Capture
- Salesforce integration patterns and best practices
- Salesforce API rate limits and native integration advantages
Sources
- Salesforce Developers, Bulk API and Bulk API 2.0 Limits and Allocations. 2/ Salesforce Developers, Change Data Capture Allocations: delivery allocations by edition and 72 hour retention. 3/ Salesforce, Data 360 Zero Copy Connectivity and the Zero Copy Partner Network: supported platforms, query and file federation, bidirectional sharing. 4/ Salesforce Help, Bring Your Own Lake data federation. Verified 2 September 2026.
