Can Power BI Connect to Google Cloud?

Can Power BI Connect to Google Cloud?

Yes, but not to all of it. The gap between "Google Cloud" and "the parts of Google Cloud that Power BI actually ships a connector for" is where most of the frustration on this topic lives.

Power BI has certified connectors for BigQuery. It does not have one for Cloud Storage, and it does not have one for Cloud SQL. Those three facts explain nearly every dead end people hit when they open the Get Data dialog expecting a Google Cloud option and find only part of what they wanted.

This guide walks the documented paths as Microsoft and Google publish them, and flags where the two vendors' own documentation disagrees with itself. There are more of those than you would expect.

What is the short answer?

Power BI connects to Google Cloud through four certified Google connectors in Power Query, and BigQuery is the only one that matters for serious analytics work. Microsoft's connector index carries exactly four Google-branded entries — Google Analytics, Google BigQuery, Google BigQuery (Microsoft Entra ID), and Google Sheets — all listed as available for Power BI semantic models and Power Query Online.

Everything else in Google Cloud is reached some other way, or not at all:

• BigQuery — two certified connectors, both supporting Import and DirectQuery.
• Google Cloud Storage — no Power Query connector. Reachable only on the Fabric side, through Data Factory pipelines or a OneLake shortcut.
• Cloud SQL — no documented path from either vendor. Google's own Cloud SQL connection guide does not mention Power BI or any BI tool by name.
• Anything else — the generic ODBC or REST route, using the drivers Google publishes.

So the honest answer is that Power BI connects very well to BigQuery, adequately to Sheets and Analytics, awkwardly to Cloud Storage, and not in any documented way to Cloud SQL.

Not sure whether your reporting stack is actually wired up the way you think it is? Get a free SEO and analytics audit and find out what your data is really telling you.

Why are there two BigQuery connectors?

Because they solve two different identity problems, and Microsoft never explains which to pick.

The standard Google BigQuery connector

This is the original. Its authentication kinds are OAuth and Service Account Login, and its stated prerequisite is terse: a Google account or a Google service account. Its data source kind is GoogleBigQuery and its function is GoogleBigQuery.Database.

The service account path has one quirk worth knowing before you fight it: once you download the JSON key, all new lines must be removed so the contents sit on one line. In the Power BI service and Power Query Online the fields are relabeled, with Username mapping to the service account email and Password to the JSON key contents.

The Google BigQuery (Microsoft Entra ID) connector

This one authenticates with a Microsoft Entra ID account. Its data source kind is GoogleBigQueryAad, its function is GoogleBigQueryAad.Database, and it carries one hard requirement the standard connector does not: a Billing Project ID, which Microsoft states is required for the use of this connector and must be set in Advanced settings.

Which one should you use?

Microsoft does not say, and that is the single most useful thing to know going in. The Entra ID connector's page contains no comparison with the standard connector, no decision table, and no "use this when" guidance of any kind.

The only sourced rationale lives on Google's side: its Workforce Identity Federation guide instructs you to pick the Entra ID connector, because that is the one accepting the audience URI its federation flow produces. So choose the Entra ID connector when you are federating Microsoft Entra groups into Google Cloud, and the standard connector otherwise.

There is also a status conflict you should not paper over. Microsoft lists the Entra ID connector's release state as general availability. Google's page, updated November 7, 2026, calls it "Google BigQuery (Microsoft Entra ID) (Beta)" in both its Desktop and Web instructions. Two vendors, same connector, two labels.

How do you connect Power BI to BigQuery, step by step?

The standard connector is the short path.

1. Open Get Data in Power BI Desktop and search for Google BigQuery. Pick the plain entry unless you are deliberately federating through Entra ID.
2. Choose your authentication. Sign in with a Google account for OAuth, or supply the service account email and the flattened JSON key.
3. Set the Billing Project ID in Advanced settings. Optional on the standard connector, required on the Entra ID one. Do it anyway.
4. Pick your connectivity mode. Import or DirectQuery, both supported.
5. Select your datasets and tables in the Navigator. If your projects do not appear, that is a permissions problem, not a connector problem.
6. Load or transform. Nested fields arrive as JSON text columns, so plan a transform step.

If you publish to the service and your data sits behind a firewall, you also need an on-premises data gateway. Microsoft's two connector pages disagree on the minimum version for the new driver — the standard page says May 2025, the Entra ID page says July 2025 — so treat those as per-connector numbers rather than merging them.

What about the federated Entra ID path?

Google documents a five-step setup on its side: create a workforce identity pool at the organization level, register a Microsoft Entra app with Microsoft Graph permissions, create a provider mapping Entra groups into Google Cloud, grant that group BigQuery access, then connect using the billing project ID and the audience URI. Google also publishes limits Microsoft does not, including a maximum of 999 groups fetched and a session duration between 15 minutes and 12 hours.

Working out whether your analytics setup is costing you visibility? Run a free audit and see where the gaps are before you build another report on top of them.

When should you use each route?

Match the route to the shape of the data, not to the logo on it.

• BigQuery with DirectQuery — when the dataset is too large to import and users need current numbers. Accept that you pay BigQuery for every query a visual fires.
• BigQuery with Import — when the data fits, or when scan costs matter more than freshness. The right default for most reports.
• Google Sheets — small reference tables and hand-maintained lookups. Import only.
• Google Analytics — GA4 data via the Data API. Import only.
• Cloud Storage through Fabric — when you need files, not tables. Pipelines and Copy job only.
• Generic ODBC — when nothing certified fits. Google has collaborated with Magnitude Simba to provide ODBC and JDBC drivers, the escape hatch for everything without a connector.

What are the limitations worth knowing?

This is the part the Get Data dialog does not tell you, and most of it comes from Microsoft's own known-issues sections.

The DirectQuery DateTime bug

Both connectors carry the same documented issue: the DateTime type is not supported through DirectQuery, and selecting a column of that type causes an invalid query error or a visual error. This is not obscure — timestamp columns are everywhere in BigQuery, so budget time for casting them.

Nested fields become JSON text

The connector supports nested fields, but loads them as text columns in JSON format, which you then parse and expand manually in Power Query. Worth noting what Microsoft never addresses: REPEATED fields and arrays are not discussed anywhere. Nested RECORD handling is documented; repeated-mode behavior is not.

The billing project default is undefined

If no Billing Project ID is provided, Microsoft says the first available project returned by Google APIs is used — without saying which project that will be. Set the value explicitly rather than discovering which project got billed.

The Navigator does not show everything

Three documented traps. Connect to your billing project, not the data project. The Browser role or equivalent is needed at project level for projects to appear. And granting BigQuery Metadata Viewer at only the dataset level is explicitly called out as insufficient.

Separately, a known issue says the connector does not currently support materialized views in the Desktop navigator. Fetch them with a native SQL query instead.

Refresh collisions

Simultaneous report refreshes can trigger a quota error. Stagger refresh schedules, set a billing project, and keep GoogleBigQuery.Database calls in the same query as the schema and table selection.

A driver migration is underway

Both connectors are moving from the embedded Simba ODBC driver to the BigQuery ADBC driver. The old implementation is labeled V1 and described as legacy; V2 is the recommended option for new workloads.

Be careful how you read the timeline, because every milestone Microsoft publishes is hedged as "planned" and "subject to rollout readiness", running from a tenant-setting rollout in 2026 to the old drivers no longer shipping with Desktop or the gateway by spring 2027. There is no committed end-of-support date, and Microsoft notes you cannot permanently opt out.

The new driver brings its own gaps. Relationships are not supported, proxy is not supported on the Entra ID connector, and it works only in 64-bit Desktop. There is no per-file toggle, so moving an existing query over means deleting it, re-adding the source, and re-selecting the fields.

One more deserves naming: a known issue says partitioned semantic models might not refresh correctly, with a note that a fix "should be deployed in October 2025." That sentence still sits on a page updated in October 2026. Microsoft never confirms it shipped.

Reporting on data you cannot fully trust is worse than not reporting at all. Book a free audit and get a clear read on what is actually working.

The audience URI contradiction

This one is awkward. Google's federation guide tells you to enter an audience URI. Microsoft's Entra ID page says cloud connections do not support the optional parameter Audience Uri, and ignore custom values you provide through it. One vendor requires the field; the other calls it optional and ignores it.

How does this compare to the alternatives?

If BigQuery is your warehouse, the comparison is less about capability than friction.

Looker Studio is Google's own tool and needs none of this: no billing project parameter, no key flattening, no gateway, no driver migration. It is the path of least resistance for BigQuery, and the weaker choice if your reporting already lives in Power BI.

Tableau is worth noting because of who Google names. Google's "Integrate with third-party tools" page lists Looker Studio, Looker, Vertex AI Workbench and Tableau as native BigQuery API integrations. Power BI is not on that list, and appears in Google's documentation only on the Workforce Identity Federation page. That asymmetry tells you which vendor is doing the integration work.

Microsoft Fabric is where the Google story is broader than Power BI's. BigQuery is supported across Dataflow Gen2, pipelines and Copy job. Cloud Storage is the inverse: pipelines and Copy job only, and the OneLake shortcut route is read-only regardless of the user's permissions.

Picking a BI stack around a warehouse you already pay for? Start with a free audit and get an outside read on where your reporting is leaking value.

A generic connector is the fallback for everything uncertified, and it is the same answer we reached for a different platform in our guide to connecting ServiceNow to Power BI — when there is no first-party connector, the API plus a generic route is the documented path, not a hack.

Final thoughts

Power BI connects to Google Cloud, but "Google Cloud" is not one thing, and the answer changes sharply depending on which service you mean. BigQuery is well served. Sheets and Analytics work for what they are. Cloud Storage requires Fabric, and Cloud SQL has no documented path from either vendor at all.

The more useful takeaway is how much of this is undocumented rather than unsupported. Microsoft never says which BigQuery connector to choose. It does not enumerate the extra permissions the new driver needs, pointing at a GitHub repository instead. It quantifies the connection timeout at 15 seconds, then says the command timeout "depends on the driver default." It publishes no row limits and no case-sensitivity statement, and states neither an API-enablement nor a billing-enabled-project prerequisite.

Build with that in mind. Set the billing project explicitly, cast your timestamps before you reach DirectQuery, and check IAM roles at project level rather than dataset level. The connector works. It just expects you to have read the known-issues section first.