Scheduled queries get expensive because cost multiplies by frequency, not because any single run is large. A query that scans a big table costs a little when you run it once by hand, but on an hourly schedule it runs roughly 720 times a month, so a modest per run charge compounds into a major recurring line. It hides well: the spend never spikes, it just accrues every hour, so it survives reviews that look for anomalies rather than steady drains. The discipline is twofold. First, scan less per run by partitioning and clustering the source tables and processing only new rows incrementally instead of rescanning history. Second, run less often by matching each schedule to how fresh the output truly needs to be, since hourly is rarely required where daily would do. Wrap both in ownership, labels, scheduled reviews, and cost controls so a runaway query is capped rather than open ended.
Here is how the compounding works, and the guardrails that contain it.
Why do scheduled queries get expensive?
The arithmetic is the whole story. Under BigQuery on demand pricing you pay per terabyte scanned, so the cost of a scheduled query is bytes scanned per run times runs per month. Frequency is the silent multiplier most teams ignore at setup.
| Schedule | Runs per month | Cost relative to daily |
|---|---|---|
| Every 15 minutes | About 2,880 | Roughly 96 times |
| Hourly | About 720 | Roughly 24 times |
| Every 6 hours | About 120 | Roughly 4 times |
| Daily | About 30 | Baseline |
The same query that costs a baseline amount daily costs about 24 times as much hourly, for output that is often no fresher than the consumer needs. Frequency is usually the first and cheapest lever to pull.
How do you make each run cheaper?
Attack bytes scanned, because every saving there is multiplied by the schedule. Partition source tables by date and cluster on common filter columns so a run prunes to the recent slice it actually needs rather than rescanning the full history every cycle. Better still, make the job incremental: process only rows added since the last run and append to a target table, so cost tracks new data, not total data. Select only required columns, never select star, since BigQuery bills the columns touched. Materialise repeated aggregations once rather than recomputing them in every downstream scheduled query. Each of these cuts per run cost, and because the schedule repeats the query hundreds of times, the monthly saving is the per run saving multiplied by frequency.
How do you keep scheduled queries from drifting?
Treat a schedule as a standing cost that must keep justifying itself. Give every scheduled query an owner and a label so its spend lands in the allocation model and someone is accountable. Review the most expensive scheduled queries on a regular cadence from the billing export, retiring jobs whose output nobody reads anymore, a common and pure saving. Set custom cost controls and maximum bytes billed limits so a query that suddenly scans far more than expected is capped rather than billing without bound. The goal is that no recurring job runs more often, or scans more, than its consumer requires, and that any drift is caught at the next review rather than at the next invoice.
A worked example
A European SaaS company found that a cluster of scheduled queries had become one of the larger lines on its GCP data bill, without any single job ever looking large. Most ran hourly out of habit, several rescanned full history every run, and a few fed dashboards no one had opened in months. We matched each schedule to real freshness needs, dropping many from hourly to daily, rewrote the heaviest jobs to process only new partitions incrementally, retired the dead ones, and set maximum bytes billed caps on the rest. The recurring data spend fell sharply with no loss of useful freshness, and the caps meant a future runaway query would be contained automatically. Figures are verified against billing data and anonymised.
Frequently asked questions
Why do scheduled queries get expensive?
How do you make scheduled queries cheaper?
How do you keep scheduled queries from drifting?
Bring discipline to recurring jobs
We audit BigQuery scheduled queries, right size their frequency and scans, and put cost controls around them so recurring data spend stops compounding, as an independent advisory that takes zero provider commissions and answers only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the GCP committed use discount kit, read the deeper GCP cost optimization guide, and choose the right model with on demand versus capacity pricing in BigQuery.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.