BigQuery for business: what it is and how to use it a data warehouse explained without SQL
BigQuery is Google's cloud data warehouse: a separate place you copy data into, so that it sits side by side and keeps its history. Below, without SQL: how it differs from your CRM database and from a spreadsheet, how to tell you need one, how the bill is calculated, and when it is fairer to say a spreadsheet will do.
- 1 TBof query data processed per month at no charge, alongside 10 GB of storage. Google Cloud price list
- 3 signalsdata for one decision spread across systems, questions nobody answers without an export, a report that takes over an hour to assemble
- 90 daysafter that long untouched, a table drops to a storage rate half the price. Google Cloud price list
- 3,506 timeshow often in 30 days our AI agent reached into the warehouse with no human involved; audit log, caveat in the FAQ
Short answer
What is BigQuery and how do you know whether you need it?
BigQuery is Google's cloud data warehouse. You copy data into it from the CRM, the shop, the accounting system and the ad accounts, and it keeps them side by side so you can ask one question of all of them at once. It replaces none of those systems and changes nothing inside them. It only reads.
You need it when at least two of three conditions hold. Data for a single decision sits in several systems. Questions come up that nobody answers without an export to a spreadsheet. Assembling one recurring report takes somebody more than an hour a week. When none of them holds, a warehouse gives you one more thing to maintain and takes no work away.
The bill runs on volume, not on a subscription: you pay for the data a query processes and for storage. Per the Google Cloud price list, the first terabyte of queries in a month and the first 10 GB of storage carry no charge, and a B2B company with a handful of sources counts its data in gigabytes.
How is a data warehouse different from your system's database?
Your CRM, your shop and your accounting software all have a database too, built for one job: handling what is happening right now. That database has to save an order, show a customer record and issue an invoice. Ask it „how did this metric look month by month over two years” and you end up at an export limit.
A warehouse exists to answer questions, not to run sales. Data arrives in it as a copy, in the shape it had at source, and nobody overwrites it, so the history survives even after the source system pruned it a year on. What you then do with it is a separate decision: a dashboard, a report, or an AI agent that queries the warehouse in a plain sentence.
| What it covers | System database, a CRM for example | Data warehouse |
|---|---|---|
| Why it exists | to run the current operation: an order, an invoice | to answer questions about history and several sources at once |
| Scope of data | one system, one slice of the company | every source side by side, under one definition |
| History | ends where the system decides to end it | stays in the raw layer, because nobody overwrites it |
| A question about two years back | an interface limit, or an export in pieces | one query, a result in seconds |
| Who maintains it | the system administrator or the vendor | no server to watch over, just a cloud project |
| What you pay for | a subscription, usually per user | the data a query processes, plus storage |
A warehouse does not replace those systems. It reads a copy from them, so an outage in the warehouse does not stop sales.
A spreadsheet holds data too, so why a separate warehouse?
A spreadsheet is a good tool and it usually stays in the company for good, because it holds targets, manual corrections and the things that live in no system at all. The trouble starts when it plays the part of a warehouse: somebody pastes exports from five places into it and builds the board report on top.
That is where the limit shows. The point is not that the spreadsheet is bad. The point is that its strengths, freedom and hand editing, are exactly what a warehouse is not allowed to have.
- Row limits: with two years of orders the file stops opening, so somebody trims the history
- Overwriting: yesterday's version of a number is gone, because nobody copies the file before every update
- Formulas: the margin definition lives in a cell one person understands, and their holiday stops the report
- Manual work: the same export every week, and one wrong column ruins the whole report
How do you know a warehouse is what you need?
Not from the size of the company and not from the number of orders. From what the road between a question and a number looks like. Three signals, and we check them in the workshop before anyone says the word BigQuery.
One signal is not yet a reason. Two out of three mean it is worth costing the warehouse against the cost of the manual work. All three mean the company is already paying for not having one, except the bill arrives in team hours. That is the moment for a conversation about AI data analysis, where the warehouse is the first step rather than the goal.
- Data for one decision sits in several systems: the shop knows orders, the CRM knows deals, accounting knows invoices, nobody knows the whole
- Questions come up that nobody answers without an export: which customer grew year on year, what the margin on that line was
- A recurring report takes over an hour: the same export every week, plus the time spent explaining why two numbers disagree
- The check: count those hours for a month and multiply by the hourly cost from your own payroll. That is the number you compare the warehouse against
What does BigQuery cost, and why can one bad query hurt?
The model differs from a subscription, and that is where most of the confusion comes from. You pay for two things: the data a query processes, and storage. You do not pay for server time or for the number of people opening the report. Per the Google Cloud price list, the first terabyte of queries in a month and the first 10 GB of storage carry no charge, and a table nobody has touched for 90 days moves to a storage rate half the price.
The surprise comes from the bill depending on the query, not on how much data you keep. A query that reads every column of a whole table is billed on the whole table, even when the result is a single row. Refresh that hourly in a dashboard and it becomes a standing line on the invoice.
Hence partitioning. The table is split by date, usually by day or by month, and a question about March touches March instead of reading the entire history. Nothing changes for you: the table still looks like one table and you ask it the same way. What changes is how much data reaches the bill, and that is a difference of an order of magnitude.
Where does the data sit and who gets access?
A dataset is created in a specific location, and BigQuery runs the queries in that location. For a European company that means a European one: the EU multi-region, or a single European region. The decision is made once, because changing it means moving the data rather than flipping a setting in a panel.
The second thing is access. Permissions are granted on the dataset and on the view, not on the whole project, so a department head sees their own slice and columns holding personal data can be masked. The warehouse stands in your Google Cloud project and on your billing account, including when somebody outside builds it.
- Dataset location chosen at the start, because changing it means moving the data
- Access granted on the dataset and the view, not on the whole project
- Columns with personal data masked, the rest of the dataset open
- The query log stays in your project: you can see who asked and about what
When is a warehouse overkill?
More often than the literature on data would suggest. If every number in the company fits in one spreadsheet, one person looks after it and nobody asks about history older than a year, BigQuery repairs nothing.
You get more out of the reports inside the shop or the CRM, one tidy spreadsheet with named columns, and a decision about which number is the binding one. You come back to the warehouse conversation when a second sales channel appears, or when somebody asks about margin per product.
The order is simple: first agree which questions you want answered, then check whether the answer can come out of what you already run. If it can, stay there. If it cannot, a warehouse is a cheap step, because it starts at a free tier rather than at buying a server.
How do you start if a warehouse makes sense?
Not by moving everything at once. By taking one question nobody answers today without an export, and the two sources needed to answer it. That is how we work when connecting BigQuery to company systems, and the first tables land in the warehouse in week one.
Write down questions, not systems
List five questions that come up at board level and whose answer is produced by hand today. What data you need follows from them. A list of systems drawn up without this step is always too long.
Pick two sources and count the volume
Take the two systems you cannot answer the first question without, and check how many records they hold and how far back. You compare that number against the free tier: 1 TB of queries and 10 GB of storage per month.
Create the dataset and set the limits
A dataset in a European location, tables partitioned by date, a daily spend limit on the project and a cap per query. Limits go in before the first load, not after the first invoice.
Reconcile the numbers with the source
Compare the first table with the system it came from: the sum of invoices in the warehouse has to match the sum in accounting. A gap is information, because it shows where a metric definition lives in somebody's head.
Measure at 30 and 90 days
At 30 days check whether anyone is still doing the export by hand. At 90 look at the bill and at which tables moved to the cheaper rate. You decide on the next sources using your own numbers.
Common mistakes
Five mistakes that make a warehouse cost more than it returns
The project starts with picking the tool, not with the list of questions
Three months on the data sits in the cloud and the board still gets its report out of a spreadsheet, because nobody agreed what the warehouse was meant to answer.
A dashboard refreshing hourly on a query that reads the whole table
The bill grows with the history of the data, although the result changes once a day. The same report on a partitioned table costs a fraction of it.
No daily spend limit on the project and no cap on a single query
One mistaken query only surfaces on the invoice, instead of stopping at a message about the limit being exceeded.
The dataset location picked on reflex, usually the US default
Changing it means moving all the data and creating the dataset again. When a customer asks where their data is processed, that turns into a project of its own.
Moving every system at once, before the first number reconciles
Discrepancies from eight sources land together and nobody can tell which come from the loading and which from a metric definition. Reconciling them takes longer than the connecting did.
Checklist
Checklist before you create the warehouse
If any line here is a no, this is not yet the moment for a first data load.
- Five questions the warehouse is meant to answer, written down before the tool is picked
- The hours that go into assembling those answers by hand today, counted
- The first two sources chosen, the rest deliberately left for later
- Record volume compared against the free tier: 1 TB of queries and 10 GB of storage
- Dataset location settled as European, before the first load
- Tables partitioned by date, daily spend limit and per-query cap in place
- The 30-day and 90-day measurement dates already in the calendar
Sources
Sources
- Google Cloud pricing for BigQuery: billing for query data and storage, free tiers of 1 TB and 10 GB per month
- BigQuery documentation: datasets, locations and partitioned tables
- JustAutomate, BigQuery integration: what lands in the warehouse from each system and how often
- JustAutomate, AI automation agency: our own deployments with the measurement method and the caveats
Let us find out whether you need a warehouse
Half an hour is enough to settle this
On a free 30-minute consultation you tell us how many systems your data sits in today and which numbers the board asks about. We will say plainly whether BigQuery is the first step, or whether it is order in what you already run. The process workshop costs EUR 3,500 net per week and ends with a list of sources and a plan you can execute without us.
Book a free consultationFrequently asked questions
What is BigQuery?
It is Google's cloud data warehouse: a separate place holding copies of the data from your systems, so that one question can be asked of all of them at once. The service is serverless, so there is no database to administer and no backups to watch. You create a project in Google Cloud and load the first table.
How is a data warehouse different from an ordinary database?
A system database runs the current operation: it saves an order, shows a customer record, issues an invoice. A warehouse answers questions about history and about several sources at once, so it keeps data in the shape it had at source and nobody overwrites it. The year-on-year trend exists even after the source system deleted its archive.
How much does BigQuery cost for a small company?
You pay Google by volume: for the data your queries process and for storage. Per the Google Cloud price list, the first terabyte of queries in a month and the first 10 GB of storage carry no charge, and a table untouched for 90 days drops to a rate half the price. A B2B company with a CRM and a shop counts its data in gigabytes, so it usually stays inside the free tier.
Do you have to know SQL to use BigQuery?
To write queries, yes. To get numbers out of the warehouse, no. Metrics are written once as views, and a dashboard in Looker Studio or Power BI then reads from them. On those same views you can put an AI agent that turns a question asked in a sentence into SQL and comes back with the result and the name of the table it used.
Does data in BigQuery stay in the European Union?
That depends on the location you pick when the dataset is created. For a European company the natural choice is the EU multi-region or a single European region, and BigQuery runs queries in the location of the dataset. You cannot change it later without moving the data, so the decision is made before the first load.
When is BigQuery overkill?
When every number in the company fits in one spreadsheet, one person looks after it and nobody asks about history older than a year. A shop with a few hundred orders a month gets more out of the reports inside the shop than out of a warehouse somebody has to maintain. We say that on the consultation, before anyone pays for a workshop.
Do you keep your own data in a warehouse?
Yes, and it is the only proof we can show without asking a client for permission to publish their figures. At our founders' agency an AI agent reached into the warehouse 3,506 times in 30 days with no human involved; the source is its audit log for the 30 days before 2 September 2026, counted by the type of tool called. CAVEAT: that is the scale of work taken over by the machine, not a measurement of reporting time before and after go-live, because nobody measured that time before.