Running the Databricks commit through a cloud marketplace retired the same dollars against the AWS or Azure commitment, a double dip worth 5 to 12 percent of total cloud cost that no rate negotiation produces
Two commitments, one spend. The routing decision is made by procurement in an afternoon and is worth more than the discount the account team spends a quarter defending.
Prepared by Redress Compliance · August 18, 2026 · Data platform advisory. 12 to 18 negotiations including Databricks benchmarked, 2024 to 2025.
Executive summary
Buying through a cloud marketplace retired 100 percent of the spend against the AWS or Azure commitment. The same dollars counted twice, worth 5 to 12 percent of total cloud cost across the estates benchmarked.
Estates consuming under 80 percent of committed DBUs returned their discount through breakage. Unused commit expires, so an oversized commitment gives back exactly what the negotiation won.
First proposals assumed 50 to 100 percent consumption growth. Measured growth in the same estates ran 20 to 40 percent, which is the gap that creates the oversized commit in the first place.
Commit discounts of 20 to 40 percent track the size and term of committed spend, not seat counts, so the sizing decision and the discount decision are the same decision.
How does Databricks charge, and against what?
In DBUs, at a per DBU rate that varies by SKU, tier and cloud, published on the Databricks pricing page. On classic compute your cloud provider bills the underlying infrastructure separately, so the platform cost is always two invoices deep.
That two invoice structure is what makes the routing question worth money, and it is the part most business cases model as one number.
| Element | What it sets | Where buyers misprice it |
|---|---|---|
| DBU rate by SKU | Jobs, All Purpose, SQL and Delta Live Tables differ | Workload mix moves cost more than volume does |
| Tier multiplier | Enterprise features raise the per DBU rate | Paid on workloads that never use the features |
| Cloud split | The same workload prices differently per cloud, and Azure Databricks bills through Microsoft | Compared on rate card rather than on total |
| Commit discount | 20 to 40 percent off rate card, scaling with size and term | Sized to the vendor's curve rather than measured growth |
The commit is the deal
Discounts track the size and term of the committed spend rather than any seat count. So the sizing decision and the discount decision are not two conversations, they are one, and sizing comes first.
Why does the purchase route change the economics?
Because the same dollars can retire two obligations. Buying the Databricks commit through the AWS Marketplace or its Azure equivalent draws the spend down against your hyperscaler commitment as well as your Databricks one.
Across the estates benchmarked that double dip was worth 5 to 12 percent of total cloud cost. It requires no discount concession from anyone, which is why it rarely features in a negotiation summary.
This is a procurement routing decision, not a commercial one. Nobody has to give anything up for it to work, which is exactly why it goes unnoticed. The account teams on both sides are paid to discuss rate.
The Databricks procurement playbook
Sizing the DBCU commit from measured consumption, the marketplace routing, the serverless repricing, and the clauses that protect an overshoot.
Get the brief →What 12 to 18 data platform negotiations showed
Across roughly 12 to 18 data platform negotiations Morten Andersen benchmarked in 2024 and 2025 that included Databricks, commit sizing decided the economics more than the rate did.
Estates that consumed under 80 percent of committed DBUs effectively returned their negotiated discount through breakage. Unused commit expires, so the discount and the overshoot cancel each other out.
Buyers who ran the commit through a cloud marketplace retired 100 percent of the spend against their AWS or Azure commitment. That double dip was worth 5 to 12 percent of total cloud cost and needed no concession from the vendor.
First proposals assumed consumption growth of 50 to 100 percent year over year. Measured growth in the same estates ran 20 to 40 percent, which is precisely how an oversized commitment gets signed with everyone acting in good faith.
The commit sizing argument itself is worked in our brief on the Databricks negotiation. This page is about where the same dollars go once the size is settled.
- Your quote benchmarked against 500,000+ real closed deals, adjusted for size, region, and industry
- Committed DBUs modeled against trailing consumption, with breakage priced per year
- Commit, rate protection and exit language flagged with the exact quote and the page
How should the commit be sized?
From measured trailing consumption plus verified pipeline growth, then with a safety margin taken off rather than added on. The forecast in the first proposal is a sales artifact, not a plan.
- Use measured growth, not the adoption curve, because the gap between the two was 50 to 100 percent assumed against 20 to 40 measured.
- Price breakage explicitly at 80 percent consumption, which is the level below which the discount is fully returned.
- Model the workload mix, not just the volume, since Jobs, All Purpose, SQL and Delta Live Tables carry different rates.
Serverless changes the forecast
Serverless SKUs bundle compute into the DBU rate, so a commit forecast built on classic compute misprices new workloads. The two invoice structure collapses into one and the old model stops describing the bill.
What anchors the conversation?
A priced alternative on part of the estate, and the honest arithmetic of the marketplace route. Comparable platforms publish their own rate cards, including Snowflake, which makes a workload level comparison possible rather than rhetorical.
The anchor does not need to be a migration plan. It needs to be a number somebody has actually built for a defined workload.
The same commitment shape recurs across the data platform estate, worked in our briefs on Snowflake and MongoDB Atlas.
Route before you negotiate rate
The marketplace question should be settled before the commercial conversation starts, because it changes the effective cost of every scenario in the discussion. Our brief on marketplace as a commitment lever works that mechanism in full.
What the negotiations measured, 2024 to 2025
Two cuts of the engagement file frame where the money actually moved.
Where the commit ran through a cloud marketplace and retired the hyperscaler commitment with the same dollars.
Against 20 to 40 percent measured in the same estates, which is how an oversized commit gets signed in good faith.
The first number is free and the second is expensive, and both are decided before anyone argues about the DBU rate.
Watch the briefing · 6:45They Sell the Curve, You Keep the RateConsumption commitments are sold on the adoption curve and paid on the meter. Sizing to what you can prove is the whole defense.
Your first five moves
- Settle the purchase route before the rate conversation, because the marketplace double dip was worth 5 to 12 percent of total cloud cost on its own.
- Size the commit from measured trailing consumption, not from the adoption curve that assumed 50 to 100 percent growth against 20 to 40 measured.
- Price breakage at the 80 percent line, below which the negotiated discount is returned in full.
- Model the workload mix by SKU and check the tier uplift, which is paid on workloads that often never use the features.
- Rebuild the forecast for serverless before you sign it. The negotiation practice settles routing and sizing before the rate is discussed.
Frequently asked questions
What is the marketplace double dip?
Buying the Databricks commit through a cloud marketplace retires the spend against your AWS or Azure commitment as well as your Databricks one. It was worth 5 to 12 percent of total cloud cost across the estates benchmarked.
Does the marketplace route require a concession?
No, which is why it is missed. It is a procurement routing decision rather than a commercial one, and both account teams are paid to discuss rate instead.
What happens if we do not consume the commit?
Unused commit expires. Estates consuming under 80 percent of committed DBUs effectively returned their whole negotiated discount through breakage.
How wrong are first proposals on growth?
They assumed 50 to 100 percent consumption growth year over year, against 20 to 40 percent measured in the same estates.
How large is the commit discount?
Between 20 and 40 percent off rate card, scaling with the size and term of the committed spend rather than with any seat count.
Why does workload mix matter more than volume?
Because Jobs, All Purpose, SQL and Delta Live Tables carry different per DBU rates, so the same volume costs different amounts depending on where it runs.
What does serverless change?
Serverless SKUs bundle compute into the DBU rate, so a forecast built on classic compute misprices new workloads and the two invoice structure collapses into one.
Is the tier uplift always worth paying?
Not always. Enterprise tier features raise the per DBU rate across the board, and many estates pay that uplift on workloads that never use the features.
How should the commit be sized?
From measured trailing consumption plus verified pipeline growth, with a safety margin subtracted rather than added, and breakage priced explicitly at the 80 percent line.
What is the right order of decisions?
Route, then size, then rate. The routing changes the effective cost of every scenario, so settling it last means negotiating against the wrong numbers.
