What is Google BigQuery: how it works, costs and where to start

How BigQuery works, in five ideas

1. It is serverless. Google’s own description: you do not provision instances or virtual machines; BigQuery “automatically allocates computing resources as you need them”. Compute is measured in slots, which are virtual CPUs.

2. Storage and compute are separate. Data sits in storage that is billed by size. Queries borrow compute only while they run. That is why a table you never query costs little, and why a busy month does not require a bigger server.

3. Storage is columnar. BigQuery stores each column separately, and a query reads only the columns it names. SELECT order_id on a wide table reads one column; SELECT * reads all of them. Most cost advice for BigQuery follows from this one fact.

4. Everything is a job. Every load, export, copy and query runs as a job with an ID, a user and a record of the bytes it processed. BigQuery keeps that record for six months, which is what makes usage auditable. See query history.

5. The hierarchy is project, dataset, table. A project holds billing and permissions. A dataset is a folder of tables in one location. A table holds rows. A full table name reads project.dataset.table.

What BigQuery costs

Two things are billed, in the Iowa region as of October 2026:

• Queries, on demand: $6.25 per TiB scanned, with the first 1 TiB each month free. The alternative is capacity pricing, per slot-hour.
• Storage: about $0.023 per GiB per month for active data, with the first 10 GiB free, and less for data untouched for 90 days.

Batch loading data and running a query that fails cost nothing. A query’s cost depends on the bytes it reads, not on the rows it returns, so LIMIT does not make a query cheaper. The full picture, with worked examples, is in BigQuery pricing.

How to start for free

The BigQuery sandbox lets you use BigQuery without a billing account, inside the free limits. It is enough to learn the interface and run real queries on public data. Setup is in getting started with the BigQuery sandbox.

A first query that works in any project, on a public dataset:

SELECT
  event_name,
  COUNT(*) AS events
FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20210101' AND '20210107'
GROUP BY event_name
ORDER BY events DESC
LIMIT 5;

We ran it on 6 October 2026: it returned page_view first, with 85,636 events, and scanned about 8 MB. More to practise on in BigQuery public datasets, and a tour of the console in the BigQuery interface.

Getting data in

Writing SQL

BigQuery’s dialect is GoogleSQL. If you know SQL from another database, most of it carries over; the differences are in the functions and in how nested data is handled.

Start here: BigQuery SQL guide, then the three ideas most queries need: JOIN vs UNION, WHERE vs HAVING vs QUALIFY and common table expressions.

Function references, each with tested examples:

• Dates and times: date, datetime and timestamp functions, and which of the three types to use.
• Text and types: string functions, CAST and SAFE_CAST, conversion functions and COALESCE.
• Nested data: arrays and JSON.
• Analysis: aggregate, window and conditional functions.

Managing tables

• Create, change and remove tables: creating and deleting tables, ALTER TABLE and DML.
• Keep queries cheap: partitioned tables and materialized views.
• Reuse logic: views.
• Undo a mistake: time travel.
• Control access: IAM roles and permissions.

Getting data out

• To a spreadsheet: how to connect BigQuery to Google Sheets.
• To a file: export to CSV.
• To a dashboard: BigQuery visualization tools.
• To a model: BigQuery ML.

Who BigQuery suits, and who it does not

It suits teams that want to analyse a lot of data without running infrastructure, whose workload is uneven, and who already use Google’s tools: GA4, Google Ads and Search Console all export to it natively.

It is a weaker fit for applications that need many small, fast reads and writes per second. BigQuery is built for analysis over large tables, not for serving an app. And it rewards attention: with on-demand pricing, a careless query on a large table costs real money, so someone has to own cost hygiene.

What BigQuery does not give you

BigQuery stores the data and runs the SQL. It has no opinion about what your numbers mean. “Revenue”, “active customer” and “session” are whatever each query says they are, and in a busy project several queries say different things.

That gap is where OWOX Data Marts fits. A Data Mart is a query you wrote, saved with a description and an owner, run in your BigQuery project and delivered as reports to the spreadsheets and dashboards people use. OWOX does not replace BigQuery, hold your data or transform it. It gives the queries that define your business numbers a home, so the definition is written once.

Google BigQueryHow to load data into BigQuery: every method and when to use itOctober 6, 2026→Google BigQueryGoogle Search Console to BigQuery: bulk export setup and SQLOctober 6, 2026→Google BigQueryHow to connect GA4 to BigQuery: setup, limits and first queriesOctober 6, 2026→

See all articles →