How to reduce BigQuery costs without compromising performance

BigQuery’s fully managed, serverless model makes it a favorite for fast, scalable analytics—but its ease of use can come at a price. Without intentional design, teams often face unpredictable BigQuery bills driven by inefficient queries, poorly organized tables, and unchecked data growth.

To keep BigQuery costs under control, you need to understand where spend comes from—and how to design your data workflows for efficiency.

Understanding BigQuery's pricing model

BigQuery’s costs break down into two core components:

• Compute: You pay for the queries you run, based on the number of bytes processed. You can choose between on-demand pricing (pay-per-query) or capacity-based pricing (pre-purchased slots, like virtual CPUs).
• Storage: Charged based on the amount of data stored in BigQuery tables. Active storage is priced per GB per month, with lower rates for long-term storage.

There are also add-on costs for advanced features like BigQuery ML, BI Engine, and streaming inserts.

💡 Tip: You can monitor your project’s spend in real time using Google Cloud billing reports.

Understanding these cost drivers is the foundation for strategic optimization. In this post, we’ll walk through practical ways to reduce BigQuery costs—highlighting real examples from dbt users who’ve dramatically lowered spend using incremental models, better table design, and smarter query logic.

Using incremental models to reduce processing costs

One of the biggest cost-saving moves in BigQuery is adopting incremental models with dbt. Rather than rebuilding entire tables every time a model runs, incremental models only process new or updated data—saving time and compute.

This approach is ideal for large datasets that change frequently but only in parts (e.g., daily transactions, event logs, or application activity).

Real results from teams using dbt and BigQuery

• Bilt Rewards cut $20,000 in monthly BigQuery costs by switching to efficient incremental models with dbt.
• Enpal slashed their monthly data spend by 70% after implementing dbt across their modern data stack.
• Symend decreased their daily warehouse usage by 70% while cutting data latency from 12 hours to 2 hours—all with incremental modeling.

Keeping data warehouse costs low was critical for our leadership team. By bringing on a dbt Labs Resident Architect, we would save months of trial and error. Without their expertise, our costs would have continued increasing while we figured out incrementality.

Ben Kramer Senior Director of Data Analytics

Read the case study

Best practices for incremental models in BigQuery

• Use filters on both source and target tables Apply WHERE clauses to narrow the scope of new data—and avoid scanning the entire table unnecessarily.
• Add clustering keys to improve block pruning Columns like user_id, event_date, or order_id help BigQuery skip irrelevant data when processing.
• Use incremental predicates to reduce scan volume Example: Instead of scanning the full target table, filter for just the last 2–3 hours. Yes, there’s a tradeoff between accuracy and cost—but it’s often worth it for lower-sensitivity datasets.
• Use dbt’s merge strategy when updates matter If your target table needs to track late-arriving records or changes, the merge strategy ensures updates are applied efficiently—without full refreshes.
• Bonus: Combine with CI/CD and testing When you treat your models like software—with CI pipelines, version control, and tests—you unlock even more efficiencies. dbt makes this easy with built-in testing, documentation, and scheduling.

Design tables the minimize scan costs

BigQuery charges based on how much data your queries scan—so the way you design tables has a direct impact on cost. Partitioning and clustering help reduce the amount of data BigQuery processes, making queries both cheaper and faster.

Use partitioning to scan only what you need

Partitioning splits your table into logical segments—typically by a DATE or TIMESTAMP column like created_at or event_date. This helps BigQuery scan only the relevant slice of data for each query.

💡 Best practice: If your data doesn’t include a time column, consider adding one upstream in your dbt models.

Cluster by frequently filtered columns

Clustering organizes data within each partition based on one or more columns (like user_id, region, or campaign_id). When you filter on these columns, BigQuery can prune irrelevant data blocks—reducing scan size and improving performance.

💡 When to cluster: Use it for high-cardinality columns that are frequently filtered—like account_id, campaign_id, or region.

Combine partitions and clusters for compound savings

For best results, use both: partition by time and cluster by filter-heavy fields. A marketing events table partitioned by event_date and clustered by campaign_id enables fast, targeted lookups—without scanning full partitions.

Design with your queries in mind

Use BigQuery’s INFORMATION_SCHEMA or query plan tools to analyze which columns are commonly used in filters, sorts, or joins. Then design partitions and clusters around those patterns.

Use dbt to build efficient, scalable models

The way you build and maintain data models in BigQuery has a major impact on performance and spend. dbt makes it easier to manage transformations as modular, testable code—enabling cost-efficient practices like incremental processing, filtering, and reusability.

• Use incremental models to limit data scanned. Instead of rebuilding entire tables, dbt can process only new or changed records—cutting compute and speeding up workflows. For large datasets, this alone can save thousands in query costs.
• Filter source and target data. Narrow your model’s scope by applying filters on both sides of the transformation. This minimizes data scanned during incremental runs and keeps tables lean.
• Cluster by unique keys. Apply clustering to columns used in filters (like user_id or event_date) to enable block pruning. This lets BigQuery skip over irrelevant data during processing.
• Use incremental predicates strategically. There’s a tradeoff between cost and completeness. A rolling time window (e.g. “last 24 hours”) might miss late-arriving data but dramatically reduces bytes processed.

Write cost-efficient queries

In BigQuery, query design directly impacts your bottom line. Efficient SQL can dramatically reduce the amount of data scanned—saving both time and money.

Here’s how to trim unnecessary compute from your queries:

• Avoid SELECT *. Always specify the columns you need. Pulling all columns—even when unnecessary—forces BigQuery to scan more data.
• Filter early and often. Apply WHERE clauses as soon as possible in your query logic. The sooner irrelevant rows are excluded, the less data gets processed.
• Use approximate functions like APPROX_COUNT_DISTINCT() when perfect precision isn’t necessary. These reduce data scanned while delivering fast, directional insights.
• Pre-aggregate for reuse. If your team repeatedly runs the same metrics, materialize them in summary tables or dbt models. This avoids recalculating expensive aggregations on raw data.
• Review high-cost queries regularly. Use the BigQuery UI or INFORMATION_SCHEMA to identify the queries consuming the most resources. A small refactor can often lead to outsized savings.

💡 Tip: Pair query optimization with dbt’s model-level control. Breaking complex transformations into modular steps makes it easier to spot inefficiencies and reuse logic across your project.

Cut costs with caching and temp tables in BigQuery

BigQuery offers built-in caching and flexible table options that can cut costs without changing your query logic.

Take advantage of automatic caching

BigQuery caches query results for 24 hours by default—at no additional cost. If an identical query runs again within that window (and the underlying data hasn’t changed), BigQuery serves the cached results instantly.

To make the most of this:

• Standardize common queries across teams
• Avoid unnecessary query variation (e.g., column order, whitespace)
• Use views to enforce consistent query patterns

Use temporary or materialized tables

For expensive queries that power multiple downstream analyses, consider writing results to:

• Temporary tables – These exist only during the session and can support iterative development without long-term storage costs.
• Materialized tables – For repeated use, materializing results (e.g., with dbt) saves on reprocessing. You’ll pay once for the query, then reuse the results cheaply.

This approach is especially helpful when:

• Multiple teams access the same outputs
• Queries require multiple joins or transformations
• You’re powering dashboards or reports with tight SLAs

Real-world success stories

These aren’t just theoretical strategies—organizations using BigQuery and dbt together are seeing real, measurable cost savings and performance gains.

Bilt Rewards

By implementing efficient incremental models in dbt, Bilt reduced its BigQuery costs by $20,000/month. They also cut analytics spend by 80% after adopting the dbt Semantic Layer, moving away from embedded BI tools and eliminating duplicated logic across the stack.

Read the case study -->

Symend

Symend decreased daily warehouse credit usage by 70% with an incremental model strategy powered by dbt. This also slashed data latency from 12 hours to just 2 hours, improving timeliness for downstream teams.

Read the case study -->

Siemens

With better table design and smarter data engineering practices, Siemens reduced dashboard maintenance costs by 90%, and dropped daily load time from 6 hours to just 25 minutes.

Read the case study -->

AXS

AXS used incremental models and modular dbt pipelines to speed up deployments by 50% and reduce maintenance effort by 40%. This let their data team ship faster without increasing BigQuery costs.

Read the case study -->

Build fast, spend smart with BigQuery + dbt

Managing BigQuery costs isn’t about cutting corners—it’s about building a smarter analytics foundation. With thoughtful strategies like incremental modeling, partitioned table design, query optimization, and smart caching, teams can significantly reduce spend without sacrificing performance.

And when you combine BigQuery’s scalable processing with dbt’s modular, testable transformations, cost-efficiency becomes a built-in part of your workflow:

• Reduce data scanned by processing only new or changed records with incremental models.
• Prevent rework and errors with automated testing and CI/CD for SQL.
• Improve team velocity by building reusable logic in a shared, governed layer.

Whether you’re running mission-critical pipelines or scaling analytics org-wide, dbt helps you get the most from BigQuery—on your timeline and your budget.

🚀 Ready to see how dbt can help your team control BigQuery costs? Try dbt or book a demo today.

BigQuery Cost Optimization FAQs