Why Data Warehouse Costs Require Separate Treatment
Snowflake and BigQuery have pricing models that are structurally different from cloud compute costs, which means standard FinOps approaches — tagging, right-sizing, Reserved Instance coverage — apply only partially or not at all.
Snowflake charges for compute (virtual warehouses measured in credits per hour) and storage separately. BigQuery charges for query processing (bytes scanned) and storage separately. Both platforms can generate surprising bills because the cost of a single poorly-written query or an unintentionally large warehouse can be significant.
This post covers a practical cost governance framework for mid-market data teams running Snowflake or BigQuery, typically with one to three data engineers responsible for platform cost.
Snowflake Cost Governance
The Four Snowflake Cost Drivers
Snowflake costs fall into four categories: virtual warehouse compute, serverless feature usage, cloud services, and storage. For most mid-market teams, virtual warehouse compute represents 70-80% of the total bill.
Virtual warehouse right-sizing. Snowflake virtual warehouses come in T-shirt sizes (XS through 6XL). Each size increase doubles the credit consumption rate. The correct warehouse size for a given workload is the smallest size that completes the workload within the required time window.
Most teams default to L or XL warehouses and never revisit the decision. In our experience, 40-60% of Snowflake workloads at mid-market companies can run on a warehouse one size smaller than currently configured with no meaningful latency impact.
Identify candidates by running Snowflake's query history view filtered by warehouse size and execution time. Workloads that complete in under 30 seconds on an L warehouse are often not using all available compute — they are parallelism-limited or waiting on I/O. Moving them to an M warehouse costs 50% fewer credits with similar execution time.
Auto-suspend and auto-resume. Every Snowflake warehouse should have auto-suspend configured at 60 seconds for interactive warehouses and 0 seconds (immediately after the query finishes) for scheduled pipeline warehouses. A warehouse that sits idle for 10 minutes at XL size costs 32 credits — roughly $3-6 depending on your contract rate — for zero work done.
Query cost attribution. Configure warehouse resource monitors with notifications at 80% and hard limits at 100% of monthly budget. Assign separate warehouses to separate teams or workload types (ETL, BI tools, ad-hoc queries) — this enables attribution and prevents a runaway query in one team's warehouse from consuming another team's credit budget.
Clustering and query efficiency. Poorly-written queries that scan full tables instead of using partition pruning are the single largest source of avoidable Snowflake cost. A full scan of a 100GB table costs far more than a filtered query that prunes to 1GB. Enforce query review for any dbt model or Snowflake procedure that moves more than 10GB of data.
Snowflake Storage Optimization
Snowflake charges for the compressed size of stored data, including all Time Travel versions. Review Time Travel retention settings for each table: the default is 90 days for Enterprise accounts. For non-critical tables, reducing Time Travel to 7 days cuts storage costs for historical data by 60-70%.
Identify tables with significant storage that are not actively queried using the INFORMATION_SCHEMA storage views. Tables not queried in 90 or more days are candidates for archiving or dropping.
BigQuery Cost Governance
The Two BigQuery Pricing Models
BigQuery offers two pricing models: on-demand (charged per byte of data scanned by queries) and capacity pricing (a flat reservation of compute slots billed hourly or monthly). The choice between them depends on your query volume and predictability.
On-demand pricing is appropriate for teams with irregular query patterns — a few hundred queries per day with significant variation. At on-demand rates of $5-6 per TB scanned, teams with under $2,000-3,000 per month in query costs almost always prefer on-demand for its simplicity.
Capacity pricing (Standard or Enterprise editions) is appropriate for teams with predictable, high-volume query patterns. The break-even against on-demand pricing depends on your specific usage pattern but typically occurs at $3,000-5,000 per month of on-demand spend.
Reducing BigQuery Scan Costs
Query scan costs in on-demand BigQuery are directly controllable through table design and query patterns.
Partitioning. Partition tables by date or another high-cardinality column that queries commonly filter on. A query with WHERE date >= '2026-01-01' on a date-partitioned table scans only the relevant partitions rather than the full table. This is the single highest-ROI intervention in BigQuery cost optimization.
Clustering. Cluster tables by columns frequently used in WHERE and JOIN conditions. Clustering reduces bytes scanned for filtered queries within a partition. Combine partitioning and clustering for the highest scan reduction.
SELECT * elimination. Queries that select all columns scan all columns. In BigQuery's columnar storage, selecting 5 columns from a 50-column table scans 10% of the data. Review dashboards and dbt models for unnecessary column selection.
Query cost budgets. BigQuery allows setting a maximum bytes billed per query using the maximum_bytes_billed parameter. Set this in your data pipeline orchestration and BI tool connections to prevent runaway queries from generating unexpected costs.
Cost Governance Practices Applicable to Both Platforms
Cost attribution by team or use case. Both Snowflake and BigQuery support labeling or tagging queries and jobs. Require that all production jobs include a label identifying the team, pipeline, and purpose. This enables cost attribution reports that identify which team or pipeline is driving cost growth.
Scheduled job consolidation. Many mid-market data stacks have accumulated redundant scheduled queries — multiple jobs that process the same source tables for slightly different downstream consumers. A quarterly audit of scheduled jobs typically identifies 20-30% that can be consolidated or eliminated.
Storage lifecycle management. Both platforms charge for data you are not using. Review your largest tables quarterly. Data that is retained purely for historical audit purposes is often better archived to object storage (S3, GCS) at a fraction of the cost.
Frequently Asked Questions
What is the most common Snowflake cost mistake at mid-market companies? Warehouses with auto-suspend set to 10 or 15 minutes instead of 60 seconds. A single XL warehouse sitting idle for 8 hours costs 256 credits — $25-50 depending on contract rate — for no work done. Auto-suspend at 60 seconds is a zero-risk change with immediate cost impact.
How do we get visibility into which Snowflake queries are most expensive? Query SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY filtered by CREDITS_USED_CLOUD_SERVICES and EXECUTION_STATUS = 'SUCCESS' over the last 30 days. Sort by credits used. The top 20 queries by cost are almost always addressable through query optimization, warehouse right-sizing, or scheduling changes.
When should we move from BigQuery on-demand to capacity pricing? When your monthly on-demand spend consistently exceeds $3,000-5,000 and your query patterns are predictable enough to benefit from reserved slots. At under $2,000/month, on-demand pricing is almost always cheaper when you factor in the operational overhead of managing slot reservations.
How do we enforce query cost governance without slowing down analysts? Configure budget alerts and soft limits rather than hard blocks for analyst workloads. Hard limits that stop queries mid-execution create negative experience; alerts that notify the analyst and their manager when a query exceeds a cost threshold create accountability without blocking work. Reserve hard limits for automated pipelines.
If you want a reviewed assessment of your Snowflake or BigQuery cost baseline and optimization opportunities, contact us for a free data platform cost review.
