Why a warehouse bill doesn't behave like a software bill
Most enterprise software is priced by seat or by contract tier. A finance team can forecast it a year out. Data platforms like Snowflake and Databricks are priced by consumption: credits burned per second of compute, DBUs consumed per query. The bill moves with usage, and usage moves with how many people run how many queries against how much data on any given day.
That model has a real upside. Teams pay for what they use instead of pre-buying capacity they might not need. It also has a real cost: nobody can look at a contract and know what next quarter's invoice will be. A single unindexed join, a dashboard that refreshes every minute instead of every hour, or a data science notebook left running overnight can move the number by a meaningful margin, and the person who caused it is rarely the person who sees the bill.
The industry has started treating this as its own discipline
The FinOps Foundation, the nonprofit body that sets practice standards for cloud cost management, formally expanded its framework in 2025 to include data cloud platforms as a distinct technology category, alongside public cloud, SaaS and data centers (FinOps Foundation, 2025). The Foundation's own guidance names Snowflake, Databricks, BigQuery, Redshift and Microsoft Fabric as the platforms this scope covers, and it flags the same problem practitioners describe informally: consumption-based data pricing is variable and hard to attribute to a specific team or workload without extra instrumentation (FinOps Foundation, 2025).
The Foundation's State of FinOps 2025 report, its fifth annual survey of practitioners at large cloud-spending organizations representing a combined $69 billion in cloud spend, found that 37.8% of FinOps teams were already actively managing data cloud platform costs, with another 34.2% expecting to take it on within the next 12 months (FinOps Foundation, 2025). Put plainly: by the time this scope was named, most large organizations were already scrambling to catch up to it.
What actually drives the number
Three mechanics account for most of a data platform bill.
Compute sizing. A Snowflake virtual warehouse or a Databricks cluster is provisioned at a size, and that size determines the hourly rate regardless of whether the query running on it needs all that capacity. Oversized warehouses are a common source of waste, and Snowflake's own cost documentation recommends starting small and scaling up only when query performance data shows a warehouse is undersized (Snowflake, "Understanding Compute Cost").
Idle time. Snowflake bills per second with a 60-second minimum each time a warehouse starts, and a warehouse left running between queries keeps consuming credits until it hits its auto-suspend threshold. The default is 600 seconds; workloads with irregular query patterns often benefit from cutting that down (Snowflake, "Understanding Compute Cost"). Databricks has the equivalent problem with cluster auto-termination, where a cluster left idle bills for the time it runs even if no job executes on it (Databricks, "Best Practices for Cost Optimization").
Workload isolation. Running an ad hoc analyst query on the same warehouse as a production ETL pipeline means the two compete for capacity and get billed together, which makes it difficult to tell which team or job actually drove the spend. Separating workloads onto dedicated warehouses or clusters is slower to set up but is the clearer way to attribute cost.
Snowflake and Databricks price this differently
Snowflake charges per credit, and the dollar value of a credit depends on edition: on-demand AWS US East pricing runs roughly $2 per credit on Standard Edition, $3 on Enterprise, and $4 on Business Critical (Snowflake, "Pricing"). A given warehouse size consumes a fixed number of credits per hour regardless of edition, so the edition choice alone can move total spend by a wide margin before a single query runs.
Databricks charges per DBU, and the rate depends on both the workload type and whether the compute is classic (a self-managed cluster, billed for the time it runs) or serverless (spins up per query, no idle billing). Databricks' pricing documentation lists SQL classic compute at a lower per-DBU rate than serverless SQL, reflecting the convenience of not managing idle time directly, though exact figures vary by cloud provider and region and are worth confirming against the current pricing page before budgeting (Databricks, "Pricing"). The practical difference: Snowflake's cost lever is mostly warehouse size and suspend timing; Databricks' cost lever is mostly the classic-versus-serverless choice plus cluster autoscaling.
What to look at before adopting a cost-control approach
Anyone evaluating how to keep a warehouse bill in check, whether through native platform settings or a third-party monitoring tool, should check for three things. Does it attribute cost at the query or job level, not just the warehouse or cluster level; a monthly total by warehouse tells a finance team what happened but not who to talk to. Does it alert before a spend threshold is crossed rather than reporting it after the invoice arrives. And does it distinguish cost from value: a warehouse that costs more but replaced three smaller ones and cut pipeline runtime in half is not the problem, even though its own line item went up.
What commonly goes wrong
Teams default to sizing warehouses for peak load and never resizing down, which pays for capacity that sits unused most of the day. They set auto-suspend timers too generously because nobody wants a warehouse cold-starting mid-query, then pay for idle minutes that add up across dozens of warehouses. And they treat cost monitoring as a one-time cleanup rather than a recurring review, so the same waste patterns reappear a quarter later as new pipelines and dashboards get added without anyone revisiting the compute they run on.
Sources: FinOps Foundation · FinOps Foundation · State of FinOps 2025 · Snowflake Docs · Snowflake Pricing · Databricks Docs · Databricks Pricing