Data warehouse cost optimization: compute and storage discipline

Quick answer

Data warehouse cost is compute (running queries and transformations) plus storage, priced differently by platform: Snowflake by warehouse credit-seconds, BigQuery by bytes scanned (or slots), Redshift by node-hours. Across all, the levers are the same: scan less data (partitioning, clustering, columnar pruning, avoiding SELECT *), right-size and auto-suspend compute so it does not run idle, materialize expensive repeated queries, and separate or schedule heavy workloads. Compute usually dominates, so query efficiency and not running idle are the main savings.

Modern data warehouses separate compute and storage and price them differently, but the cost drivers are consistent: the compute that runs queries and transformations dominates, storage is secondary, and the way to save is to scan less data and not run compute when idle. The platform specifics differ; the discipline is shared.

How warehouses price compute

Warehouse	Compute pricing
Snowflake	Warehouse credit-seconds (size x runtime)
BigQuery	Bytes scanned (on-demand) or slots (capacity)
Redshift	Node-hours (provisioned) or serverless RPUs

Snowflake bills a running virtual warehouse per second by size, so idle running warehouses and oversized warehouses waste money. BigQuery on-demand bills bytes scanned, so scanning less directly saves. Redshift bills node-hours, so right-sizing and pausing clusters matters. Different meters, same principle: less compute and less scanning.

Scan less data

The universal lever is scanning less: partition and cluster tables so queries prune to relevant data, select only needed columns (columnar storage means SELECT * scans everything), filter early, and avoid repeatedly scanning large tables. On BigQuery this directly cuts bytes-scanned cost; on Snowflake and Redshift it means queries finish faster on smaller warehouses. The scan-less discipline applies everywhere.

Do not run compute idle

On credit and node-based warehouses (Snowflake, Redshift), compute running while idle is pure waste. Enable auto-suspend so warehouses stop quickly when idle and auto-resume on query, right-size warehouses to the workload (a bigger warehouse costs proportionally more per second, justified only if it finishes queries proportionally faster), and separate workloads so a heavy job does not force everything onto a large warehouse.

Controlling warehouse cost

Scan less (partition, cluster, prune columns, filter early), right-size compute and enable auto-suspend so it never runs idle, materialize or cache expensive repeated queries rather than recomputing, schedule heavy transformations off peak on appropriately-sized compute, use capacity/committed pricing (BigQuery slots, reservations) if steady high usage makes it cheaper than on-demand, and set storage retention. Because compute dominates, query efficiency and not running idle are the biggest savings, feeding the broader pipeline picture.

FAQ

What drives data warehouse cost?

Compute (running queries and transformations) plus storage, priced differently by platform: Snowflake by warehouse credit-seconds, BigQuery by bytes scanned or slots, Redshift by node-hours. Compute usually dominates, so scanning less data and not running compute when idle are the main savings, with storage secondary.

How do I reduce data warehouse cost?

Scan less data (partition, cluster, prune columns, filter early, avoid SELECT *), right-size compute and enable auto-suspend so it never runs idle, materialize or cache expensive repeated queries, schedule heavy transformations off peak, use capacity/committed pricing if steady high usage makes it cheaper than on-demand, and set storage retention. Compute dominates, so query efficiency and not running idle matter most.

Why does scanning less data reduce warehouse cost?

On bytes-scanned pricing (BigQuery on-demand) it directly reduces cost since you pay per byte scanned. On credit and node-based warehouses (Snowflake, Redshift) it means queries finish faster on smaller compute, reducing credit-seconds or node-hours. So partitioning, clustering, column pruning, and early filtering cut cost on every warehouse, just through different meters.

What is auto-suspend and why does it matter?

Auto-suspend stops a virtual warehouse or cluster quickly when it goes idle, and auto-resume restarts it on the next query. On credit- and node-based warehouses (Snowflake, Redshift), compute running while idle is pure waste, so enabling auto-suspend with a short idle timeout ensures you pay only while queries actually run, a key cost control.

Should I use a bigger warehouse to save money?

Only if it finishes queries proportionally faster. A bigger warehouse costs proportionally more per second, so it saves money only when the extra size reduces runtime enough to offset the higher rate (finishing a query in half the time on a double-size warehouse is cost-neutral but faster). Right-size to the workload; bigger is not automatically cheaper or more expensive per query.

Does C3X estimate data warehouse cost?

C3X prices provisioned warehouse infrastructure (Redshift nodes, reserved capacity) from your Terraform, so the fixed compute cost appears before deploy. Consumption-based cost (Snowflake credits, BigQuery bytes scanned) depends on query volume and efficiency, which you model as usage assumptions to estimate the full warehouse cost.

What to do next

Price your data warehouse before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.