Connecting Data 360 to Google BigQuery: the zero-copy connector, the auth choice, and the bidirectional bridge

There’s a specific moment in a lot of Data 360 projects where the architecture diagram stops being aspirational and becomes a bill. Someone points at the box labeled “customer data” and says: that already lives in BigQuery, we spent two years getting it there, we are not copying it into Salesforce. Historically that sentence was the start of an argument. With the BigQuery connector now generally available, it’s the start of a config.

Google BigQuery is one of the handful of warehouses Data 360 can reach with true zero copy — query it in place, share unified profiles back into it, and never run the ETL job that would have duplicated the whole thing. We’ve written about what zero copy moves and what it costs in general; this is the BigQuery-specific version, because the general story skips the two decisions that actually determine whether your connection is secure, performant, and cheap: how Salesforce proves who it is to Google, and which way the data flows. Get those right and BigQuery behaves like a native part of Data 360. Get them wrong and you get slow queries, a key-management headache, or a credit line you didn’t forecast.

What “zero copy to BigQuery” actually means

Zero copy is not one feature. On the BigQuery connector it’s two directions that people conflate constantly, and they have different setups, different performance characteristics, and different reasons to exist.

• Query federation (data in). BigQuery tables become queryable inside Data 360 without ingestion. Data 360 stores only metadata — where the data lives, its schema, how to read it — and surfaces the table as an external data lake object (DLO) that points at the physical rows still sitting in BigQuery. When you query it, Data 360 pushes as much of the work as it can down to BigQuery over JDBC (predicates, aggregations), so BigQuery’s own engine does the heavy lifting and only results cross the wire. This is what you set up when BigQuery is the source of truth and you want it grounded into Salesforce.
• Data sharing (data out). Data 360 objects — including the unified profile you built from other sources — are exposed as live, queryable views inside BigQuery. Your data-science team reads Salesforce’s unified customer straight from BigQuery, no export, and as activation enriches those objects the fresh values flow back out. This is what you set up when Salesforce is the source of truth and the warehouse team wants it without an integration job.

The word that matters is bidirectional. Most teams arrive wanting federation (pull BigQuery in to ground an agent or a segment) and discover six months later that sharing (push the unified profile back out) is the half that changes how the analytics org works. Design for both from the start even if you only turn one on first.

One mechanical point that pays off downstream: because a federated table lands as an external DLO, it still has to be mapped into your data model like any other source — the Data Lake Object to Data Model Object mapping is the step that decides whether your BigQuery data is actually usable in segments, insights, and identity resolution, or just technically present. Zero copy gets the bytes reachable; the mapping makes them mean something.

The decision that shapes the whole connection: how Salesforce authenticates to Google

This is the part the quickstarts gloss and the security review does not. Data 360 supports two authentication methods to BigQuery, and they are genuinely different postures, not two spellings of the same thing.

Option A — key-based auth with a service-account JSON key

You create a Google Cloud service account, generate a private key JSON file, and hand it to Data 360. Simple, works immediately, and every security engineer reading this just winced — because a downloaded service-account key is a long-lived credential that now lives in two places and has to be rotated, stored, and audited forever. It’s fine for a proof of concept. For production it’s the thing your next access review flags.

Option B — identity federation with Salesforce as a trusted broker

The better production posture: Workload Identity Federation, where Salesforce acts as a trusted identity broker and Google issues short-lived credentials on demand, so there’s no downloaded key to manage, leak, or rotate. You set it up in Google Cloud under IAM & Admin by creating a Workload Identity Pool and adding Salesforce as a provider, then binding it to the service account. It’s more setup up front and materially less risk for the life of the connection.

The guidance is blunt: use identity federation for anything production. Key files are how zero-copy connections become the finding in next year’s audit. The federation path exists specifically so that a data-sharing bridge between two of your most sensitive systems doesn’t depend on a JSON file in someone’s password manager.

The permission that fails quietly: Large Result Set

Whichever auth method you pick, the service account needs the right IAM permissions — and there’s one that trips people up because the failure it produces looks like something else. To enable Large Result Set (LRS) handling, the service account must be able to write scratch tables and datasets in BigQuery: grant bigquery.tables.create and bigquery.datasets.create, via a predefined role or a purpose-built custom role carrying exactly those and nothing more:

# A least-privilege custom role for the Data 360 connection's service account.
# Beyond read access to the datasets you federate, LRS needs create rights on
# scratch tables/datasets — the permissions whose absence fails silently.
gcloud iam roles create data360Federation \
  --project=YOUR_PROJECT_ID \
  --title="Data 360 Zero-Copy Federation" \
  --permissions=bigquery.datasets.create,bigquery.tables.create,bigquery.tables.getData,bigquery.jobs.create

Miss the create permissions and small queries work fine in testing, then a real analytical query that returns a large result set fails in a way that reads like a connector bug rather than a missing grant. Provision them on day one and save yourself the ticket.

The performance lever nobody mentions: data locality

Zero copy trades storage cost for network cost. You stopped paying to duplicate the data; you started paying, in latency, every time a query has to reach across to where it lives. The single biggest thing you control here is region colocation — put your Data 360 instance and your BigQuery dataset in the same cloud region, or as close as the geography allows, so federated queries aren’t crossing a continent per call.

This matters most for the workloads where latency is the whole point. Grounding an agent on a live record or serving a real-time segment against federated BigQuery data means the round trip is in the critical path of something a human or an agent is waiting on. Two levers keep it honest:

• Lean on pushdown. The connector’s value is that predicates and aggregations execute in BigQuery, so only results travel. Queries that can’t be pushed down — certain joins, functions BigQuery evaluates differently — fall back to dragging more data across the wire. Watch for the ones that don’t push down; they’re your slow, expensive queries.
• Federate the reference data, ingest the hot path. Zero copy is not automatically the right answer for every table. High-velocity data that an agent hits on every interaction sometimes belongs ingested for latency, while the vast historical estate stays federated for cost. That’s an architecture call, not a default.

What it costs — and why federation is usually the cheap answer

Here’s the number that makes the whole pattern worth the setup. On the Data 360 rate card, zero-copy federation meters at roughly 70 credits per million rows accessed, against 2,000 credits per million rows for a batch ingestion pipeline — call it a ~28x difference on the same data. You’re paying to look at the rows in place instead of paying to copy them in, and looking is far cheaper than copying.

That spread is the entire economic argument for zero copy, but it comes with two footnotes that belong in the credit-optimization conversation:

• “Rows accessed” is not “rows returned.” A federated query that scans a wide table with a weak filter meters on everything the engine touches, not the tidy result set you got back. An unfiltered BI tool polling federated data on a tight schedule is the classic way a “nearly free” connection becomes a line item. Give external consumers filtered, purpose-built views and sane refresh cadences.
• Cheap per row, unbounded in volume. 70 credits per million is trivial until a nightly warehouse job starts scanning the shared objects on a loop. Zero copy removes the sync cost; it does not remove the need to watch the meter. Put the federated connection on the same weekly Digital Wallet review as everything else.

For the fuller rate-card picture and where consumption actually concentrates, the Data 360 credit optimization playbook is the companion to this post.

Connector or Iceberg? The BigQuery-native fork

The native BigQuery connector is not the only way to reach data that happens to sit in Google Cloud, and picking the wrong one is a real cost. The other path is Apache Iceberg file federation, which works at the open-table-format layer instead of a per-vendor connector. The rule of thumb:

• Use the BigQuery connector when the data lives in BigQuery as a managed table and you want BigQuery’s own engine and optimizer serving your federated queries. You get pushdown into a mature warehouse and a first-class GA connection.
• Use Iceberg file federation when the data lives as open table files in Google Cloud Storage under a catalog, or when you’re deliberately building catalog-first so no single vendor’s connector owns your access path. It trades the warehouse’s optimizer for open-format portability.

If your data is genuinely in BigQuery, the connector is almost always the right call — it’s purpose-built for exactly that and now GA. Iceberg is the answer when “it’s in Google Cloud” means files in a bucket, not tables in BigQuery. This is the same “connector versus open format” fork we walk through in the Iceberg file federation piece, applied to one specific vendor.

Where this actually pays off

Two patterns justify the connector more than any generic “unify your data” pitch.

Grounding without duplicating. You want an agent or a segment grounded on behavioral, product, or transactional data that already lives in BigQuery, and you refuse to build and babysit an ETL pipeline to copy it into Salesforce. Federation gets it grounded in place. The unified profile you build on top can then drive activation and agent context, while the source rows never leave Google.

Salesforce data in the warehouse’s ML, live. The data-sharing direction lets your team train and run models in BigQuery ML against Salesforce’s unified customer — not the raw, un-deduplicated CRM export they’ve been fighting with, but the reconciled profile Data 360 already resolved. And because Data 360 can bring an external model’s scores back in through bring-your-own-model, the loop closes: unified data out to BigQuery, a prediction back into Data 360, an activation or an agent acting on it. That round trip is the thing zero copy makes cheap enough to actually run.

If you need to reach the same unified data from outside Salesforce with SQL rather than through a warehouse share, the Data 360 Query API is the other door into the same house.

The takeaway

The BigQuery connector turns “our data lives in Google and it’s staying there” from an objection into a two-decision setup. Decision one is authentication: use Workload Identity Federation, not a downloaded key, for anything you’ll still be running next quarter. Decision two is direction: you almost certainly want both — federation to ground Salesforce on warehouse data, sharing to put the unified profile back in front of your data-science team — so design for the bidirectional bridge even if you light up one side first. Grant the bigquery.tables.create and bigquery.datasets.create permissions before your first large query, colocate the regions before you complain about latency, and keep the federated connection on the weekly credit review. Do that and you get the thing the diagram promised: one governed view across Salesforce and BigQuery, no copy, no sync job, no duplicate customer to reconcile. Standing up a zero-copy foundation that holds under real volume is the core of our Integration & Data Cloud work.

Understanding the basics

Is the Data 360 BigQuery connector zero copy and bidirectional?

Yes. The Google BigQuery connector is generally available and supports zero-copy in both directions. Query federation makes BigQuery tables queryable inside Data 360 without ingestion — they surface as external data lake objects that point at rows still living in BigQuery, with predicates and aggregations pushed down to BigQuery’s engine. Data sharing exposes Data 360 objects as live views inside BigQuery so your warehouse and ML teams read Salesforce’s unified data without exporting it. Neither direction copies or syncs the data; queries run against the source.

How does Data 360 authenticate to BigQuery?

Two ways. Key-based authentication uses a downloaded service-account private key JSON file — quick to set up but a long-lived credential you must store, rotate, and audit. Identity federation uses Workload Identity Federation, where Salesforce acts as a trusted identity broker and Google issues short-lived credentials with no downloaded key to manage. Use identity federation for production. Whichever you choose, grant the service account bigquery.tables.create and bigquery.datasets.create so Large Result Set handling works; without them, small queries pass in testing and large ones fail later.

When should you use Iceberg file federation instead of the BigQuery connector?

Use the native BigQuery connector when the data is a managed table in BigQuery and you want BigQuery’s own engine serving federated queries with pushdown. Use Apache Iceberg file federation when the data lives as open table files in Google Cloud Storage under a catalog, or when you’re deliberately building a catalog-first architecture so no single vendor’s connector owns your access path. If the data is genuinely in BigQuery, the connector is almost always the better choice; Iceberg is for lakes and open-format portability.

---

Trying to ground Salesforce on data that lives in BigQuery without building another pipeline to babysit? Talk to us — zero-copy connections that are secure, fast, and cheap to run are a normal week for our data team.