GCP BigQuery Pricing Per Query: The Real Cost After 6 Years of Running Analytics
I made a mistake in 2023. A $47,000 mistake.
We had a client — let's call them RetailCo — running analytics on a data warehouse that was costing them more in confusion than in compute. They were on AWS Redshift, paying for reserved clusters they couldn't fully utilize. When I suggested moving to BigQuery, their CTO laughed. "Pay-per-query? Sounds like a meter running while I sleep."
Two months later, after we actually tested it, he was right. And wrong. BigQuery pricing per query is both simpler and more dangerous than most people realize.
What this guide covers: Exactly how BigQuery charges you, where the hidden costs live, when to use flat-rate vs on-demand pricing, and why your "cheap query" might cost you $500 a month in storage alone.
The Two Pricing Models Nobody Explains Properly
BigQuery gives you two options. They look simple. They're not.
On-Demand Pricing (The Default Trap)
$6.25 per TB of data processed. Sounds clean. Sounds cheap.
Here's what they don't put in the docs: that's $6.25 for the first TB. You get 1 TB free per month. After that, every query you run costs you based on how much data it scans — not how much it returns.
A SELECT * on a 500GB table? That scans 500GB. You're paying $3.12 before the results even load.
I ran a test in March 2024 with a 10TB table. A single COUNT(*) — one aggregation — scanned the whole thing. Cost: $63.75. For a pointless query.
The AWS vs Azure vs GCP 2026: Same App, 3 Bills comparison shows exactly this scenario playing out across providers. Redshift would have charged for cluster uptime (say $5/hour), not per query. Different trade-off entirely.
Flat-Rate Pricing (The Commitment Game)
Reservations start at $2,000/month for 100 slots. Slots = compute capacity. You pay whether you use them or not.
For the first 6 months at RetailCo, we ran on-demand. Costs fluctuated wildly — $3,500 one week, $12,000 the next. "It's the data scientists running ad-hoc queries," their lead engineer said.
We switched to flat-rate 500 slots at $10,000/month. Predictable. But we also had to throttle queries. Suddenly, the "sleeping at 3 AM because nothing is urgent" queries competed with the "dashboard the CEO checks every morning" queries.
The hard truth nobody tells you: Flat-rate works if you have steady usage. On-demand works if your queries are carefully written. Most organizations are neither.
The Real Cost: What You're Actually Paying For
Let me break this down to the line-item level. Because BigQuery's billing schema has more hidden edges than you'd expect.
1. Compute (The Obvious One)
| Tier | Price per TB scanned |
|---|---|
| On-demand | $6.25 |
| Flat-rate (100 slots) | $2,000/month flat |
| Flat-rate (500 slots) | $10,000/month flat |
But here's the trick: BigQuery doesn't charge for all queries equally. Metadata queries (like INFORMATION_SCHEMA), cached results, and queries on tables with expiration dates older than 90 days? Free. Zero cost.
I watched a team at a fintech startup rewrite their entire reporting layer to hit the cache aggressively. Their query costs dropped 80% in two weeks. The pattern? They ran a nightly batch that materialized all dashboards as physical tables, then the dashboards queried those tables. Nothing scanned more than 100MB during business hours.
2. Storage (The Sneaky One)
$0.02 per GB per month for active storage. $0.01 per GB per month for long-term (90+ days unchanged).
If you have a 10TB table that nobody queries for 3 months, you're paying $100/month just to keep it around. That adds up.
One of my clients had 28TB of "historical analytics data" — data from 2018-2022 that exactly one person queried once every quarter. They were paying $560/month in storage. We moved it to GCS (Google Cloud Storage) and used an external table. Storage cost dropped to $140/month. Query performance? Slightly slower. Cost for that quarterly query? $2 instead of $12.
Trade-offs exist. Pretending otherwise is how you waste money.
3. Streaming Inserts (The Hidden Tax)
$0.01 per 200MB of streaming data. Sounds negligible.
At 10GB/day of streaming inserts (common for real-time analytics), that's $15/month. Fine. But at 100GB/day? $150/month. For a feature you might not even realize you're using.
The Google Cloud to Azure Services Comparison document explains how Azure's equivalent (Stream Analytics) charges differently — per streaming unit, not per volume. Different billing philosophies.
4. Data Export and Copy
Exporting data out of BigQuery to, say, a local CSV or another cloud? You're paying GCP egress rates. Those rates change. Check the AWS vs Azure vs GCP 2026: Same App, 3 Bills article for the latest comparison — egress is where clouds make their margins.
Copying data within the same region? Free. Cross-region copy? You pay for both compute and egress.
How to Actually Control BigQuery Costs
I've managed BigQuery for 20+ clients across 6 years. Here's what works.
1. Never Allow SELECT *
Sounds obvious. Everyone ignores it.
sql
-- Bad: Scans entire table
SELECT * FROM orders WHERE date > '2026-01-01';
-- Good: Scans only date column and selected fields
SELECT order_id, total, customer_id FROM orders WHERE date > '2026-01-01';
The first query on a 2TB table costs $12.50. The second costs $0.30. Same result.
2. Use Partitioning and Clustering
Partitioning by date is the single most effective cost control.
sql
-- Create a partitioned table
CREATE TABLE mydataset.orders
PARTITION BY DATE(created_at)
CLUSTER BY customer_id
AS SELECT * FROM source_data;
Now queries like WHERE date > '2026-06-01' scan only the relevant partitions. I've seen query costs drop 90% with this alone.
3. Set Query Quotas at the Project Level
GCP allows you to set custom quota limits per user per day.
bash
gcloud alpha bigquery quotas update --project=my-project --quota-type=user --limit-total-terabytes=10
This prevents the "someone ran a SELECT * on a 50TB table at 3 AM" disaster. We saved a client $17,000 in one month by enforcing this.
4. Use Materialized Views Strategically
sql
CREATE MATERIALIZED VIEW mydataset.daily_sales
AS SELECT
DATE(order_time) as order_date,
SUM(amount) as total_sales,
COUNT(*) as order_count
FROM mydataset.orders
GROUP BY 1;
Materialized views are automatically maintained by BigQuery. They're free to refresh (the incremental update is background). Your dashboards hit the view instead of the raw table. Query cost: pennies instead of dollars.
5. Set a Custom Cost Control Budget
GCP's budget alerts work. But you have to set them.
bash
gcloud billing budgets create --billing-account=XXXXXX-XXXXXX-XXXXXX --display-name="BigQuery Monthly Cap" --budget-amount=5000 --threshold-rules=percent=50,percent=90
I set this for every client. The 50% alert gives you time to react. The 90% alert means "stop what you're doing."
The Slot Allocation Problem You'll Eventually Face
Here's where theory meets practice.
In a flat-rate model, you have N slots. Each query needs M slots. If you have more concurrent queries than slots, they queue.
I worked with a SaaS company in early 2025. They had 200 slots. During peak hours (9 AM - 11 AM), their reporting queries queued for 15 minutes. The CEO complained "BigQuery is slow."
We looked at the slot utilization. Turns out, a single data scientist was running a massive training data export that consumed 150 slots for 45 minutes. Every morning. Contention killed performance.
The fix? Use BigQuery reservations:
sql
-- Assign slots to specific users/groups
ALTER RESERVATION reporting_reservation SET OPTIONS (
slot_capacity = 100,
target_job_type = "QUERY"
);
-- Assign other slots to ad-hoc queries
ALTER RESERVATION adhoc_reservation SET OPTIONS (
slot_capacity = 100,
target_job_type = "QUERY"
);
Reservations isolate workloads. The data scientist's export ran in its own reservation. Reporting queries got their dedicated slots. Problem solved. Cost unchanged.
The Microsoft Azure vs. Google Cloud Platform article mentions that Azure Synapse has similar resource-governing features — but the implementation is different enough that you can't directly compare.
When On-Demand Beats Flat-Rate (And Vice Versa)
Use on-demand when:
- You're processing less than 320 TB per month (break-even point for 100 slots)
- Your query patterns are unpredictable
- You can implement aggressive cost controls (partitioning, caching, quotas)
- Your team is small and disciplined
Use flat-rate when:
- You're processing more than 320 TB per month
- You have steady, predictable query loads
- You want predictable monthly costs for budgeting
- You have peak periods where performance matters
I've flipped clients both ways. One e-commerce company was spending $8,000/month on on-demand but could have handled 100 slots for $2,000. They just didn't know their own usage patterns. After 2 weeks of monitoring, they switched. Saved $6,000/month.
Another client — a real-time analytics platform — switched from flat-rate to on-demand after they realized 60% of their slots were idle at night. They're spending $4,500/month instead of $10,000. Same performance.
The Migration Cost Nobody Mentions
If you're considering how to migrate from aws to gcp, BigQuery pricing isn't your only cost.
You'll pay for:
- Data egress from AWS ($0.09/GB for the first 10TB/month)
- Data ingress to GCP (free)
- BigQuery load jobs ($0.01/200MB for streaming, $0.005/GB for batch)
- Schema redesign (if your Redshift schema isn't columnar-friendly)
I helped a logistics company migrate 5TB from Redshift to BigQuery in Q4 2025. Their total data transfer cost? $450 in AWS egress. Their schema redesign? Two weeks of engineering time. Their BigQuery costs for the first month? $1,200 on-demand. Previously they were paying $3,800/month for their Redshift cluster.
Worth it. But only because their workloads were analytical (joins, aggregations, window functions) — exactly what BigQuery excels at.
For transactional workloads? BigQuery isn't the right tool. The AWS vs Azure vs GCP: The Complete Cloud Comparison explains this trade-off well — each platform optimized for different patterns.
The GCP Cloud Run vs App Engine Angle
If you're running applications that feed data into BigQuery, you have infrastructure choices that impact cost.
gcp cloud run vs app engine matters here because:
- Cloud Run is cheaper for variable workloads (no idle cost)
- App Engine has built-in cron jobs for scheduled BigQuery queries
- Cloud Run's per-request pricing works well for webhook-based data ingestion
I've seen teams use Cloud Run to process webhook data, write to BigQuery streaming inserts, and then query BigQuery for real-time dashboards. It's a clean architecture — but the streaming insert costs add up.
For batch processing (nightly reports, ETL jobs), App Engine's standard environment with scheduled tasks is more cost-effective. No streaming costs, just scheduled queries.
Pick based on your data freshness needs, not your cloud provider's marketing.
FAQ: GCP BigQuery Pricing Per Query
Q: How much does a single BigQuery query cost?
A: $6.25 per TB scanned (on-demand). A query scanning 100GB costs about $0.63. A query scanning 10TB costs $62.50. Partition your tables.
Q: What queries are free in BigQuery?
A: Metadata queries (INFORMATION_SCHEMA), cached results (within 24 hours, same query), queries on tables with expiration dates > 90 days, and zero-byte results. Also free: BQML model creation (compute is free, storage costs apply).
Q: Can I set a hard cap on BigQuery spending?
A: Yes — use budget alerts (email/webhook) and custom quota limits at the project level. You can also set a maximum billing tier via reservation pricing, but on-demand has no hard cap without manual limits.
Q: Is BigQuery cheaper than Redshift for analytics?
A: For most analytical workloads, yes — if you control query patterns. Redshift charges for cluster uptime regardless of usage. BigQuery charges per query. Heavy usage patterns favor Redshift. Light or variable usage favors BigQuery. Test both with your actual queries before committing.
Q: How do I see my exact BigQuery costs per query?
A: Run SELECT * FROM INFORMATION_SCHEMA.JOBS_BY_PROJECT and look at total_bytes_billed, total_slot_ms, and cache_hit. BigQuery's audit logs also show per-query costs in Cloud Logging.
Q: Does BigQuery charge for data loading?
A: Batch loads from GCS are free (compute + storage). Streaming inserts cost $0.01 per 200MB. Load jobs from external sources (AWS S3, Azure Blob) also charge for data transfer.
Q: What's the cheapest way to use BigQuery for small teams?
A: Use the 1TB free tier, partition aggressively, cache results via materialized views, and set daily per-user quotas. Most small teams can stay under $200/month.
Q: Does BigQuery charge for failed queries?
A: Yes. If a query scans data and fails mid-execution, you pay for what was scanned. Design queries to fail early (use LIMIT 1 for exploration) or use dry_run mode to estimate cost before running.
The Bottom Line
BigQuery pricing per query isn't complicated. It's just easy to get wrong.
The $6.25/TB number makes people think "cheap." They run SELECT * on everything. A month later, they're staring at a $15,000 bill wondering what happened.
The flat-rate pricing makes people think "predictable." They buy 500 slots. A month later, they're paying for idle capacity they don't need.
The right answer? Know your data. Know your queries. Test before you commit. And for god's sake, partition your tables.
I've built systems processing 200K events/sec through BigQuery. The difference between a $2,000/month bill and a $20,000/month bill isn't the data volume — it's the discipline of how you query it.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.