All Posts

Data & Analytics

Databricks' $190 Billion Valuation Puts a Number on Consumption Pricing

Databricks' $190 Billion Valuation Puts a Number on Consumption Pricing

Bhavika J

Techshorts Editorial Team

Databricks closed a $5 billion funding round on August 13, 2026, at a $190 billion valuation, up from $134 billion in the company's previous round six months earlier (Databricks, 2026). The round was led by Coatue, with Blackstone, MGX, T. Rowe Price and new investor Sixth Street Growth also participating (Bloomberg, 2026; CNBC, 2026). Alongside the raise, Databricks disclosed that it crossed a $7 billion annualized revenue run rate in its second quarter, up from roughly $4 billion a year earlier, a growth rate the company says exceeds 80% year over year (Databricks, 2026).

Those numbers exist because of how Databricks, and its main rival Snowflake, actually charge customers. Both platforms sell compute by consumption rather than by seat or by flat license. For a buyer evaluating either platform, or trying to explain a bill that came in over budget, understanding that pricing mechanism matters more than any feature comparison.

What consumption pricing actually is

A consumption-based data platform charges for compute as it is used, not for a fixed number of licenses or a flat annual fee. Databricks meters usage in Databricks Units, or DBUs, a normalized measure of processing power billed per second (Databricks, 2026). Snowflake meters usage in credits, consumed by virtual warehouses while they are actively running queries, also billed per second with a 60-second minimum each time a warehouse starts (Snowflake, 2026).

Neither number maps directly to a dollar figure on its own. The DBU rate and the credit rate both vary by compute type, by service tier, and by cloud region. A customer's actual bill is DBUs or credits consumed multiplied by that rate, and on both platforms it arrives as compute cost from the vendor plus a separate infrastructure bill from the underlying cloud provider for the virtual machines, storage and network egress that run beneath it.

Why this model exists

Flat licensing does not fit workloads that spike. A retailer's query volume during a holiday weekend has little in common with its volume in February. A per-seat license charges the same either way. Consumption pricing lets the bill follow the workload: a warehouse that runs for ten minutes is billed for ten minutes, not a full hour, and a warehouse that sits idle costs nothing while suspended (Snowflake, 2026).

That elasticity is also what makes the model attractive to a vendor's growth story. Databricks' own disclosure breaks out product-level detail: its Lakehouse data warehousing product surpassed a $1.5 billion revenue run rate, growing over 100% year over year, and more than 1,000 customers are now consuming above a $1 million annualized run rate each (Databricks, 2026). Consumption revenue scales automatically as a customer's workload grows, without a renegotiated contract. That is good for the vendor's growth rate. It is also why a customer's bill can grow faster than expected without anyone explicitly deciding to spend more.

How the two models differ in practice

Databricks and Snowflake both bill by consumption, but the unit of measurement and what it covers are not identical.

Databricks' DBU rate depends on three things: the compute type (job compute, interactive all-purpose compute, or SQL warehouse compute), the service tier (Standard, Premium, or negotiated Enterprise pricing), and whether the workload runs as a scheduled job or an interactive notebook. Those categories can differ in rate by a factor of three to four for otherwise similar work (Databricks, 2026). Databricks' Standard tier has been retired on AWS and Google Cloud, leaving Premium as the default entry point for new deployments (Databricks, 2026).

Snowflake's credit rate depends on the edition (Standard, Enterprise, or Business Critical) and the cloud region. Each step up in warehouse size, from extra-small to the largest available size, roughly doubles both the compute power and the credits consumed per hour of active use (Snowflake, 2026).

The practical difference for a buyer: on Databricks, the same query can cost meaningfully different amounts depending on whether it runs as a scheduled job or in a notebook someone left open. On Snowflake, the same query costs roughly the same regardless of how it was triggered, but a warehouse sized for a rare peak load consumes credits at that larger size every time it runs, including for routine queries that did not need the extra capacity.

What to check before signing

Ask for the rate table by compute type and tier, not just a single blended DBU or credit price. A quote that only cites list price for the cheapest compute category understates what a real workload mix will cost.

Ask what the cloud infrastructure bill adds on top of the platform's own compute charge. That second bill is billed separately and is easy to leave out of a first-year cost estimate.

Ask how warehouses or clusters are currently sized and whether autoscaling or auto-suspend is configured by default. An oversized warehouse left running, or a cluster with no idle timeout, is the single most common cause of a consumption bill exceeding forecast.

Ask for actual usage data from a proof of concept on your own workload rather than a vendor-run benchmark. Compute cost for the same task can vary substantially by file layout, partition strategy, and query pattern, all specific to a customer's own data, not something a generic benchmark can capture.

What commonly goes wrong

Teams that adopt consumption pricing expecting it to automatically track their actual usage are often surprised by idle spend: a warehouse or cluster that keeps running after the job that needed it has finished. Auto-suspend and auto-scaling settings exist on both platforms specifically to prevent this, but they are not always turned on by default, and a team that never checks the setting can pay for capacity nobody is using.

The second common mistake is comparing a DBU rate to a credit rate as if they were the same currency. They measure different things, cover different compute categories, and sit under different infrastructure billing arrangements. A rate comparison without a matched workload behind it tells a buyer very little about what either platform will actually cost.

Sources

  1. Databricks, "Databricks Grows >80% YoY, Surpasses $7B Revenue Run-Rate, Scales Lakebase, Genie, and Unity AI Gateway" - https://www.databricks.com/company/newsroom/press-releases/databricks-grows-80-yoy-surpasses-7b-revenue-run-rate-scales
  2. Databricks, "Databricks is Raising a Strategic Round of Funding at a $188 Billion Valuation" - https://www.databricks.com/company/newsroom/press-releases/databricks-raising-strategic-round-funding-188-billion-valuation
  3. Bloomberg, "Databricks Raises $5 Billion at a $190 Billion Valuation" - https://www.bloomberg.com/news/articles/2026-08-13/databricks-raises-5-billion-at-a-190-billion-valuation
  4. CNBC, "Databricks wraps $5 billion funding round at $190 billion valuation" - https://www.cnbc.com/2026/08/13/databricks-funding-round-190-billion-valuation.html
  5. Databricks, "Serverless DBU consumption by SKU" - https://docs.databricks.com/gcp/en/resources/pricing
  6. Databricks, "Databricks Pricing: Flexible Plans for Data and AI Solutions" - https://www.databricks.com/product/pricing
  7. Snowflake, "Understanding overall cost" - https://docs.snowflake.com/en/user-guide/credits.html
  8. Snowflake, "Overview of warehouses" - https://docs.snowflake.com/en/user-guide/warehouses-overview