Connecting Claude to BigQuery: What Works in the Demo and Breaks in Production

Connecting Claude to your BigQuery warehouse now takes about ten minutes. You add the connector in the Claude app, approve access with your Google login, and you are asking your own data questions in plain English. The first session is impressive enough that most teams want to roll it out the same week.

That instinct is right. This way of working with data is clearly where things are heading, and the teams that learn it early will get more out of their data than the ones that wait. But the connection is the easy 10 percent. The other 90 percent is everything that makes the answers trustworthy and defensible: agreed definitions, sensible access, data routing, and a record of what happened. Skip those and you find out three weeks later, when a confident, well formatted, wrong number has already been forwarded to the board.

This piece is for the founder, CFO, or marketing lead who just tried this, liked it, and is now deciding how to roll it out. Here is what the quick setup gives you, the four things worth arranging before the whole team gets access, and what the reliable version looks like.

The ten minute setup

Most people connect through the Claude web or desktop app. You add a BigQuery connector, an MCP server under the hood, and each person signs in with their own Google account. That is the whole setup. No code, no keys, and permissions simply follow what everyone already has in BigQuery.

MCP, the Model Context Protocol, is the open standard that makes this plug and play possible. If the term is new, start with our plain language explainer, MCP Explained for Marketing Leaders.

Ten minutes later you type "what were our top products last month" and watch Claude find your tables, write the query, and return a tidy answer with commentary. The demo impresses for real reasons. Current models are strong at SQL, they explore an unfamiliar warehouse methodically, and they recover from their own errors in seconds.

But demos flatter the setup. The person running one knows the data, asks questions the data can support, and rephrases when an answer looks off. Daily use has none of those safety rails. Daily use is a growth marketer typing a vague question at 5pm before a budget meeting.

One practical note: every question scans data, and BigQuery bills by the amount scanned. A curious team asking broad questions over two years of history can produce a bill nobody budgeted for. Caps exist, but nobody sets them from a chat window.

Which revenue did it pick?

Ask Claude "what was revenue last month" and you will get a number. What you will not get is a warning about which revenue it picked.

Your warehouse does not store one version of an amount. It stores many. The order total with VAT and shipping still in it. The total before the discount code was applied. Orders that were placed but later cancelled or refunded. The test orders your own team put through in May. Every one of those sits in a table, and nothing in the data tells an AI which combination your finance team calls revenue.

So it picks a plausible one. Say finance closes June at €548,900: excluding VAT, after discounts and refunds, test orders removed. Claude, working from the raw tables, reports €689,412. VAT is still in there, so is shipping, the refunds never came off, and a quirk in how order lines are stored counted some multi item orders twice. Every individual choice is defensible. The total is 26 percent too high.

A CFO does not need a database course to feel this one. It is the difference between revenue including and excluding VAT, between before and after discounts, delivered by a system that sounds completely sure of itself. That number will survive three meetings before anyone checks it.

Note that nothing malfunctioned. The number is the right order of magnitude, the reasoning reads well. This is the same disease that makes Shopify, GA4, and Meta report three different revenue numbers, except now an AI is picking between the definitions on every question. The fix is a semantic layer: a single, agreed definition of every metric that the AI must use instead of guessing. We cover how that works in Why AI Gets Your Numbers Wrong, and How a Semantic Layer Fixes It.

Giving the AI less access than the person

The login side of access is actually well solved. Each person connects with their own Google account, so everyone works under the permissions they already have in BigQuery. No shared super account, nothing new to administer. For a first rollout this is perfectly reasonable.

The harder question comes right after: should the AI see everything the person can see? Often the answer is no. Someone with legitimate access to the customer table may still not want names and email addresses flowing through an AI provider on every question. And sometimes the reason is practical rather than sensitive: keep the AI away from the giant raw event tables, so one casual question cannot scan two years of history.

This is where it gets genuinely hard. BigQuery has no concept of "this person, but asking through an AI." Access is tied to the account, and the connector inherits it one to one. Making the AI's view narrower than the person's own view means real plumbing: a second identity per person, or a shared service account per team with its own grants, all of it kept in sync by hand as people join and leave. Two accounts for one person is exactly the kind of administration nobody keeps up with.

A production setup solves this at a different layer: the AI's scope is defined separately from personal warehouse rights, per role, so the marketer's question runs against marketing data and the PII stays out of reach, without anyone managing duplicate accounts.

Your numbers travel further than you think

Follow the data for one question. The question itself, the description of your tables, and the rows that come back all travel to the AI provider to generate the answer. And the rows are your business: customer emails, order values, campaign results.

By default, that traffic goes to servers in the United States. Whether the provider may keep it, for how long, and whether it can be used for training depends on which subscription each person happens to have. Consumer plans have different terms than enterprise contracts, and in the ten minute setup nobody checked which one applies.

Under GDPR this is not automatically forbidden, but it does require paperwork, transfer mechanisms, and a deliberate decision. A connector approved on a Tuesday afternoon has had none of those. The production answer is regional inference: the AI runs on EU servers, for example through Google Vertex in the Netherlands, with a contract that says nothing is retained. Your security or privacy lead will ask about exactly this, and we wrote up their full question list in The Security Review for AI on Your Marketing Data.

A record of what the AI did

The fourth thing to arrange surfaces the first time an AI sourced number turns out to be wrong, or the first time someone asks who looked at the customer table last Tuesday.

The warehouse logs that queries ran under each person's account, which helps. But the interesting half lives somewhere else: the conversation that produced the query sits in personal chat histories, spread over everyone's own Claude account. There is no central way to reconstruct the path from question to answer, which means no way to debug a wrong number, satisfy an auditor, or learn which questions your team actually asks.

A reliable setup keeps a complete trail per interaction: who asked, what they asked, what query ran, and what came back. Unglamorous, and exactly what you want on the table the first time something looks off.

The quick setup and the reliable setup, side by side

What the production version looks like

Generically, and regardless of vendor, a version you can rely on adds four layers between the chat window and your warehouse.

1. A person asks a question, and a login layer establishes who they are and which role applies.
2. The AI works from a catalog of defined metrics, the semantic layer, instead of improvising against raw tables.
3. The question becomes a query that applies the agreed definitions and the role's scope, with a cap on query cost.
4. Who asked, what was asked, what ran, and what came back are logged, and then the answer appears.

The final layer is the accuracy check: a standing set of thirty to fifty business questions you already know the answers to, rerun automatically whenever the data or the model changes. Teams skip this one most often, and it is the only mechanism that tells you accuracy slipped before a person does.

None of it works without the unglamorous prerequisite underneath: clean, tested data landing reliably in your own warehouse, which is what managed data extraction exists to solve. The remaining question is whether you build these layers yourself, which is weeks of engineering plus permanent upkeep, or buy them.

Where Verity fits

Verity is the production grade version of this setup, managed. A managed MCP server gives Claude and other models access to your semantic layer rather than your raw tables, so answers come from your definitions. Role based access is applied to every prompt, so what the AI can reach is set per role instead of inherited from personal warehouse rights. AI calls run through Google Vertex in the Netherlands with zero retention, and every question, query, and answer lands in an audit trail, all on top of a BigQuery you own. Data Chat is the same architecture with the chat interface included.

Frequently asked questions

Is it safe to connect Claude directly to BigQuery?

For a solo founder exploring non sensitive data, yes. It deserves more thought once the whole team joins: decide which tables an AI should reach, check where answers containing customer data travel, and make sure someone can reconstruct what was asked. Those are properties of the setup, not of Claude.

Everyone connects with their own account. Is access solved then?

The login part, yes: each person operates under their own BigQuery permissions. What personal OAuth cannot do is give the AI a narrower view than the person has. If PII tables or huge raw tables should stay out of the AI's reach while people keep their normal access, that separation has to be built deliberately, and BigQuery has no per tool switch for it.

Do I need a semantic layer if my warehouse is well organized?

Tidy tables and good naming help, but they are documentation, not enforcement. The AI can still pick the wrong version of revenue or count an order twice. A semantic layer is binding: the AI asks for a metric, the definition produces the query. Our semantic layer deep dive walks through the failure classes it removes.

What will a security review ask about this setup?

Where the AI runs, what is retained and whether it trains on your data, who can see what, how personal data is kept out of scope, and whether there is an audit trail. Roughly in that order. The full checklist, with what good and bad answers sound like, is in The Security Review for AI on Your Marketing Data.