Salesforce to BigQuery connector that loads CRM data into partitioned tables
The Salesforce to BigQuery integration from Adapters loads accounts, contacts, opportunities, and activity from Salesforce into BigQuery tables on an incremental schedule, so your warehouse stays analytics-ready without draining Salesforce API limits. Field mapping is no-code, so try it against sample records in the live demo.
The live demo needs no card, and Starter is $49 a month.
Field mapping auto-plugged · tap a port to rewire
Plug a source port into
Transform on this cable
JSON in
JSON out
5 sample records ready
What running Salesforce to BigQuery by hand costs you
- Full object exports burn Salesforce API calls and hit daily governor limits during business hours.
- Hand-built Python loaders break the moment someone adds a custom field or renames an object.
- Stale CRM data in BigQuery means Looker Studio dashboards and models report last week, not today.
The field mapping, out of the box
All 6 of these Salesforce to BigQuery fields arrive mapped. Rewire any of them, or add your own, in the same visual data mapping tool you use for every adapter.
Input / SALESFORCE
Output / BIGQUERY
Transforms included
Incremental loads use the Salesforce SystemModstamp watermark so each run only moves changed rows into BigQuery; Salesforce field types cast to BigQuery column types, currency stays NUMERIC, timestamps land as TIMESTAMP in UTC, and tables partition by load date so dbt models and Looker Studio read a clean, deduplicated table without scanning the whole history.
Salesforce to BigQuery load job quotas, schema drift and why the row count stops matching
The transfer is the easy part. What decides whether a Salesforce to BigQuery pipeline is still trusted in six months is how it handles quotas nobody read, a Salesforce schema that changes without telling you, and the several legitimate reasons the two row counts stop agreeing. Google Cloud quota documentation and Salesforce developer limits read 19 August 2026.
The BigQuery quota that catches incremental pipelines
BigQuery allows 1,500 load jobs per table per day and 100,000 per project per day. That is generous for nightly loads and restrictive for anything ambitious: a pipeline loading one object every 15 minutes uses 96 jobs a day per table, which is fine, but a per-object micro-batch every minute is 1,440 and leaves no headroom for a backfill on the same day. A single load job can carry up to 15 TB and must finish within 6 hours. Batch load jobs run on a free shared slot pool, so the cost pressure on this route is storage and query, not ingestion.
File and row limits that fail a load rather than warning about it
CSV and newline-delimited JSON have a maximum row size of 100 MB, and compressed CSV or ndJSON files are capped at 4 GB against 5 TB uncompressed. A table can hold 10,000 columns, which sounds impossible to reach until somebody flattens a Salesforce object with several hundred custom fields alongside every picklist expanded. The practical rule for Salesforce extracts: compress for transfer, but split before compression rather than after, because the 4 GB ceiling applies to the compressed artifact.
Salesforce meters the read side, and Bulk API 2.0 is the only sane choice
Daily API calls are 100,000 plus 1,000 per license on Enterprise and Professional, 100,000 plus 5,000 per license on Unlimited and Performance, and just 15,000 on Developer Edition, shared across every integration in the org. Bulk API 2.0 handles up to 150,000,000 records per 24 hours with a 150 MB base64 payload cap per job, 400,000 characters per record and 131,072 per field. Also watch the 25 concurrent long-running request ceiling in production: a wide SOQL query over a large object routinely crosses the 20 second threshold that counts against it.
Schema drift is a Salesforce feature, not an incident
A Salesforce admin can add a custom field on a Tuesday afternoon without telling the data team, and they should be able to. What matters is what your pipeline does next. Three behaviors exist: fail the load, ignore the new column silently, or add it to the BigQuery table. Silent ignore is the worst of the three because it produces a warehouse that is quietly incomplete and a dashboard nobody suspects. Decide which behavior you want, verify it during the trial by adding a test field, and make sure whichever one you chose produces a message a human sees.
Why the row counts stop matching, and which differences are fine
Four legitimate causes, worth distinguishing before anyone calls it a bug. Deletes: records in the Salesforce Recycle Bin vanish from a normal query but persist in BigQuery unless the extract requests them. Field-level security: the integration user cannot see fields it was not granted, so a column that is empty in BigQuery may be populated in Salesforce. Filtered extracts: a WHERE clause added months ago to speed up a sync is still there. Timing: records created between the extract watermark and the count. Only the second one is usually a genuine misconfiguration, and it is fixed with a permission set rather than with the pipeline.
What Google's own Salesforce connector lands, and what it costs
The BigQuery Data Transfer Service has a Salesforce connector, generally available and billed at $0.06 per slot-hour, with Google's planning ceiling at about $1.20 per hour of run time. Three documented details decide whether it fits. It maps Salesforce currency and percent fields to FLOAT, not NUMERIC. Incremental transfers "cannot sync delete operations in the source table". And its setup guide requires a Salesforce connected app, which Salesforce stopped letting customers create by default in Spring '26. Read from Google and Salesforce documentation on 21 September 2026; the full line-by-line comparison is on Salesforce to BigQuery integration tools, and the run-hour arithmetic on Salesforce to BigQuery connector pricing.
How Adapters handles this lane, and where it does not fit
Adapters extracts through the bulk path on a schedule you set, maps standard and custom objects with explicit BigQuery types, surfaces new source fields rather than dropping them, and logs failed records with the source values attached, on a flat monthly price from $49 with no row meter. It suits a defined set of objects kept current for reporting. It is not the pick for sub-minute streaming into BigQuery, for a project needing dozens of additional SaaS sources, or where transformation has to happen in flight rather than in SQL afterwards. The allocations that constrain any tool on this route are tabled on Salesforce integration tools.
How it goes live
Moving Salesforce data into BigQuery on flat data integration pricing from $49 a month.
STEP 01
Pick the pair
Authorize a read scope on Salesforce and a write scope on BigQuery, nothing wider.
STEP 02
Confirm the mapping
Check that Account.Id lands in dim_account.account_id and SystemModstamp in fct_opportunity.loaded_at on a sample record.
STEP 03
Schedule the sync
Turn on the SALESFORCE → BIGQUERY schedule; failed records retry and every run is logged.
Salesforce to BigQuery sync common questions
How do I load Salesforce data into BigQuery?
Extract through the Salesforce API, then load into BigQuery as partitioned tables. Use the Bulk API for the initial backfill of large objects and the REST or Query API with a SystemModstamp watermark for incremental runs. Land each object in its own table, partition on a date column, and merge on the Salesforce record ID so re-runs update rather than duplicate.
Which Salesforce objects should you sync to BigQuery?
Start with Account, Contact, Lead, Opportunity, OpportunityLineItem, User and the history objects you report on. Adding every custom object on day one is the usual mistake: it multiplies API calls, slows the backfill, and fills the warehouse with tables nobody queries. Add objects as reports demand them.
How do Salesforce API limits affect a BigQuery sync?
They set your realistic sync frequency. Salesforce enforces a daily API request allocation per org, and a naive per object full refresh burns through it fast. Incremental reads on SystemModstamp cut request volume by orders of magnitude, and the Bulk API moves large volumes in far fewer calls than the REST API.
How do you handle Salesforce deletes in BigQuery?
Query the deleted records endpoint or read the recycle bin, because a SystemModstamp watermark cannot see a row that no longer exists. Without that step, deleted opportunities stay in BigQuery forever and every pipeline report runs slightly high. Some teams also run a periodic ID reconciliation to catch hard deletes.
How does the Salesforce to BigQuery sync work?
The Salesforce to BigQuery integration from Adapters loads accounts, contacts, opportunities, and activity from Salesforce into BigQuery tables on an incremental schedule, so your warehouse stays analytics-ready without draining Salesforce API limits. Field mapping is no-code, so try it against sample records in the live demo.
How much does the Salesforce BigQuery integration cost?
The Salesforce to BigQuery pair is included on every plan: Starter $49, Growth $149, Scale $399 a month. You pay per plan, not per row or task, so a busier month costs the same.
Do I need to write code to connect Salesforce and BigQuery?
No. Fields are auto-mapped the moment you pick the pair, and you can rewire any mapping visually before the first sync. Incremental loads use the Salesforce SystemModstamp watermark so each run only moves changed rows into BigQuery; Salesforce field types cast to BigQuery column types, currency stays NUMERIC, timestamps land as TIMESTAMP in UTC, and tables partition by load date so dbt models and Looker Studio read a clean, deduplicated table without scanning the whole history.
Related Salesforce and BigQuery connectors
Browse the full api connector library, or request a pair you do not see.
Salesforce and BigQuery, finally in agreement
Map the pair once and let it sync on schedule. Flat price from $49 a month, no per-task fees.
The live demo needs no card, and Starter is $49 a month.