Data warehouse sizing cost: matching compute to your workload

Quick answer

Data warehouse cost is driven mainly by compute size times runtime: a larger warehouse costs more per hour but finishes work faster, so the cost of a query is roughly size multiplied by duration. Sizing for cost means picking the smallest warehouse that meets your latency needs, enabling auto-suspend so idle compute stops billing, and using auto-scale only for genuine concurrency spikes. Bigger is not always more expensive per job if it finishes proportionally faster, but idle time on an oversized warehouse is pure waste. Separate storage from compute and treat them as independent cost levers.

Modern data warehouses (Snowflake, BigQuery, Redshift, Databricks SQL) separate compute from storage, and compute is where most of the money goes. Compute is billed by the size of the warehouse (or slots, or credits) multiplied by how long it runs. So sizing, choosing how much compute to provision and keeping it from running idle, is the single biggest cost lever in a data warehouse.

How warehouse cost is structured

Cost component	Driver
Compute	Warehouse size times runtime (or credits/slots consumed)
Storage	Data volume stored per month, usually cheap
Data transfer	Egress and cross-region movement
Serverless features	Materialized views, auto-clustering, search

Storage is typically a small line item (a few dollars per terabyte per month). Compute dominates: a warehouse that is twice as large costs about twice as much per hour. The key insight is that a bigger warehouse often finishes a job proportionally faster, so the cost of a single query can be similar across sizes. The waste comes from idle time, a large warehouse sitting on with no queries. This mirrors the BigQuery cost model and the tradeoffs in Databricks.

Right-sizing the warehouse

Start with the smallest warehouse that meets your latency requirement, then scale up only if queries are too slow. For interactive dashboards, a small warehouse with fast auto-suspend usually beats a large one running continuously. For heavy batch transformations, a larger warehouse that finishes quickly can cost the same or less than a small one grinding for hours, because total cost is size times time. Benchmark a representative query at two or three sizes and compare total cost, not just per-hour rate.

Auto-suspend and idle time

The most common data-warehouse waste is compute left running with nothing to do. Enable auto-suspend with a short idle timeout (often 60 seconds is plenty) so the warehouse stops billing the moment queries stop. Use auto-resume so it spins back up on the next query. For workloads with bursty concurrency, multi-cluster auto-scaling adds clusters only during spikes and removes them after, so you pay for concurrency only when you need it. Idle compute is the equivalent of leaving over-provisioned capacity running.

Separate storage and compute levers

Because storage and compute are billed independently, treat them as separate optimizations. On the storage side, drop unused tables, set retention on time-travel and staging data, and compress where you can. On the compute side, size warehouses per workload (a small one for BI, a larger one for ELT), avoid one giant shared warehouse that everyone contends on, and monitor credit or slot consumption by team so you can attribute cost. Understanding these levers, and pricing them before you provision, keeps warehouse cost proportional to the value the data delivers. See the resource catalog for how warehouse resources are priced.

FAQ

What drives data warehouse cost the most?

Compute, which is billed as warehouse size multiplied by runtime (or credits and slots consumed). A larger warehouse costs more per hour but often finishes work proportionally faster, so per-job cost can be similar across sizes. The biggest avoidable cost is idle time: a warehouse left running with no queries. Storage is usually a small line item by comparison, a few dollars per terabyte per month.

How do I right-size a data warehouse?

Start with the smallest warehouse that meets your latency requirement and scale up only if queries are too slow. Benchmark a representative query at two or three sizes and compare total cost (size times time), not just the per-hour rate. For interactive BI a small warehouse with fast auto-suspend usually wins; for heavy batch a larger warehouse that finishes quickly can cost the same or less.

Does a bigger warehouse always cost more?

Not per job. Because total cost is roughly size multiplied by duration, a bigger warehouse that finishes a query proportionally faster can cost about the same as a smaller one that runs longer. The real waste is idle time on an oversized warehouse. So bigger is not inherently more expensive for a given job, but it is more expensive to leave running idle.

What is auto-suspend and why does it matter?

Auto-suspend stops a warehouse from billing after a short idle period (often 60 seconds), and auto-resume spins it back up on the next query. It matters because idle compute is the most common data-warehouse waste, a warehouse sitting on with nothing to do still costs money. Short auto-suspend timeouts ensure you pay only for compute that is actually running queries.

Should I use one big warehouse or several small ones?

Usually several sized per workload. A single giant shared warehouse creates contention and forces everyone onto the same size. Separate warehouses (a small one for BI dashboards, a larger one for ELT batch jobs) let you size each to its workload, apply different auto-suspend settings, and attribute cost by team. This is more cost-efficient than one oversized shared cluster.

How does C3X help with data warehouse sizing cost?

C3X prices data warehouse and related infrastructure from your Terraform before you deploy, so the cost implications of a warehouse size or configuration are visible in the pull request. Seeing the cost of a sizing choice at design time helps you pick the right size and settings up front, rather than discovering an oversized, always-on warehouse on the monthly bill.

What to do next

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