What BigQuery Actually Costs for a Marketing Team

Half a dollar a month. That is a realistic BigQuery bill for a store shipping 50,000 orders a year, itemized line by line below, which is why the most common objection to owning your own warehouse, fear of the warehouse bill, is misplaced by about three orders of magnitude. The horror stories are real, but they come from petabyte-scale engineering teams and from a handful of specific, avoidable mistakes. The coffee for one standup costs more than a month of BigQuery at this scale. This article shows the arithmetic, and then shows the mistakes, because knowing what makes bills explode is what makes the small bill durable.

We are assuming the ownership model here: the warehouse sits in your own Google Cloud project, so this bill is yours, paid to Google, visible in your own billing console.

How BigQuery pricing works

BigQuery has two meters, storage and queries, and you can understand both in a paragraph each.

Storage is priced per GiB per month. Active storage, meaning tables modified in the last 90 days, lists at about $0.02 per GiB per month; tables untouched for 90 days drop automatically to long-term storage at about $0.01. The first 10 GiB each month are free. These are EU multi-region list prices as of mid 2026; single European regions can run somewhat higher, so check the pricing page for your exact region.

Queries, on the on-demand model that fits marketing workloads, are priced by data scanned: $6.25 per TiB as of mid 2026, with the first TiB every month free. The word scanned matters. BigQuery charges for the columns and partitions a query reads, regardless of how many rows come back. A query that returns ten rows but reads a full two-year event table pays for the whole table. Every cost technique in this article is some version of scanning less.

That is the entire model. No cluster to size, no instance running overnight, nothing billed while idle.

A worked example: 50,000 orders a year

The example store ships 50,000 orders a year, with a GA4 property exporting about 500,000 events a month to BigQuery. Sources: the GA4 export, Meta Ads, Google Ads, order data from the store platform, and email engagement data.

Storage first. GA4 events run roughly 1 to 2 KB each in the export, so 500,000 events a month is about 0.5 to 1 GiB per month, or around 10 GiB a year. Ad platform data is daily-grain and tiny by comparison: a few thousand rows a day across both platforms adds up to well under 1 GiB a year. Orders, customers, and email events might add another 2 to 3 GiB a year. After two full years of history, the whole estate sits near 25 to 30 GiB, most of it already in the long-term tier.

Now queries. Daily pipeline runs that build models incrementally touch only the newest partition: a few hundred MiB a day, maybe 10 GiB a month. Dashboards, if they read small pre-aggregated tables rather than raw events, scan 50 to 100 MiB per refresh; a team refreshing all day gets to perhaps 50 GiB a month. Add an analyst doing genuine ad hoc exploration at another 50 GiB. Total: 100 to 150 GiB scanned per month, roughly a tenth of the free TiB.

The bill

Half a dollar. Triple every assumption and it is still under two. Even a brand ten times this size, with 5 million GA4 events a month and heavy dashboard use, typically lands in the tens of euros. Against the license fees in the full cost breakdown of a self-built stack, the warehouse is a rounding error, so cost fear should never drive the warehouse decision.

What makes bills explode

Every BigQuery horror story we have seen traces back to one of three patterns, and all three are about scanning instead of storing.

The classic is SELECT * over years of GA4 events. The export creates a table per day, and a wildcard query with no date filter reads all of them, every column, including the heavy nested ones. On our example brand that is a 25 GiB mistake, which costs nothing. On a property doing 10 million events a month for three years, it reads close to a TiB per run, and someone scheduling that query hourly turns it into a four-figure month.

The quieter one is a BI tool pointed directly at raw event tables. Live-connection dashboards re-run their queries when viewers open them, and the arithmetic compounds fast: a 100 GiB raw table, ten tiles per dashboard, twenty viewers checking a few times a day is thousands of full-table scans a month. That is hundreds of TiB scanned, more than $1,000 a month as of mid 2026 prices, for a dashboard that would read a 50 MiB summary table if someone had built one.

The third is scheduled jobs that rebuild everything. A transformation that recomputes all of history every night, instead of processing only new days, multiplies daily scan volume by however long your history is, every night, forever.

The guardrails

The defenses are standard practice and none of them are exotic.

Partition tables by date and require the filter. A partitioned table physically separates days, so a query that asks for June only reads June. BigQuery even lets you set require_partition_filter so an unfiltered query fails instead of billing you. With the GA4 export's per-day tables, the same discipline looks like this:

SELECT
  event_date,
  SUM(ecommerce.purchase_revenue) AS revenue
FROM `your-project.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260601' AND '20260630'
GROUP BY event_date

Build incrementally. Transformation frameworks like SQLMesh and dbt process only new or changed partitions on each run, so daily pipeline cost stays flat as history grows.

Point dashboards at marts, never at raw events. The aggregation runs once a day in the pipeline; viewers scan kilobytes.

Set a ceiling. The maximum bytes billed setting rejects any query that would scan more than your limit, which turns the worst case from a bill into an error message. And before running anything unfamiliar, the console's dry-run estimate shows the scan size for free.

A team that does these four things does not have BigQuery cost problems at marketing scale. The pattern in all of them is the same one from our GA4 BigQuery guide: understand what the engine reads, and make it read less.

Who pays the bill, and where Verity fits

One architectural point, because it answers a question we get on every pricing call: with a warehouse-in-your-project vendor, BigQuery costs are not included in the subscription, and that is a feature. The project is yours, so Google bills you directly, at list price, visible in your own console with no markup and no bundling. Verity works this way: the pipelines, models, and semantic layer run inside your GCP project, the BigQuery line stays on your Google invoice, and at the data volumes in this article it is usually a few euros. You can verify every number in this piece against your own billing page, which is rather the point of owning the project.

Frequently asked questions

Are BigQuery costs included in the Verity subscription?

No. BigQuery runs in your own GCP project and Google bills you directly, with no markup. For typical marketing data volumes the bill is single-digit euros a month, and you can watch it in your own billing console.

When does on-demand pricing stop being the right model?

When monthly scan volume grows to the point that the on-demand bill consistently clears several hundred euros, BigQuery's capacity-based editions with slot commitments start to win. Marketing workloads at the scale discussed here rarely get close, so on-demand with a maximum bytes billed guardrail is the sensible default.

Does the GA4 export itself cost anything?

Enabling the standard GA4 BigQuery export is free, and standard properties can export up to one million events a day. You pay only the storage and query costs described above once the data lands, which is why the export is usually the first thing worth switching on.

How do I know what a query will cost before running it?

BigQuery shows a dry-run estimate of bytes to be scanned in the console before you execute, at no cost. Divide by a TiB, multiply by $6.25, and remember the first TiB each month is free. For standing protection, set maximum bytes billed so oversized queries fail instead of billing.