SAP Business Data Cloud pricing: what is public and what is not
As of 2026-08-14
SAP does not publish a list price for Business Data Cloud, and any page quoting one is quoting a market estimate dressed as a tariff. What SAP does publish is the mechanism, and the mechanism is where the money goes: BDC is sized and billed in capacity units, a bundled measure of compute, memory, storage allotment and data-flow throughput sold in tenant-sized blocks. The smallest tenant starts at 128 capacity units, against a 64-unit floor for a standalone Datasphere tenant. The answerable question is not what it costs but what drives the number.
What is public, and what is not
Public: the unit of account and its composition, the tenant minimum, the workload types drawing against the pool, and the monitoring surface that reports consumption after go-live. That is enough to build a sizing model you can defend in front of a finance stakeholder.
Not public: the price of a capacity unit, the entry price of a tenant, the discount curve, the overflow rate past the storage allotment, and the pass-through rate for the embedded Databricks capacity. None of those are inferable from the mechanism, and every euro figure circulating for BDC is somebody's estimate — usually derived from a handful of deals and quoted without the workload profile that produced it.
This changes how a proposal should read. Quote a single number without the workload breakdown and you set up the worst version of the conversation a year later: a customer who never saw the build-up assumes they were oversold, while one who did can see which workload grew.
What one capacity unit buys
A capacity unit bundles roughly one vCPU-equivalent of HANA Cloud compute with about four gigabytes of HANA Cloud memory, plus a storage allotment before overflow pricing and a slice of data-flow throughput.
Because it is bundled, the same unit trades differently by workload: a memory-hungry, low-throughput planning model consumes in a different shape than a replication-heavy integration workload with modest memory needs. The practical consequence is that memory usually binds for in-memory analytics, not vCPU count — a sizing conversation anchored on processor cores prices the wrong variable and will under-provision a planning-heavy tenant.
The 128-unit floor is higher than a standalone tenant's for a reason: a BDC tenant is expected to carry replication, live analytics, planning, Joule and Knowledge Graph work at once, a wider mix than a semantic layer alone ever runs.
The six workloads competing for one pool
Live SAP Analytics Cloud queries running federated push-down spike hardest at peak business hours. Replication flows draw a sustained, predictable load. Analytic-model evaluation consumes at query time and scales with concurrent users. Joule grounding queries are individually cheap and multiply with active users. Knowledge Graph traversal is moderate per query and infrequent. Databricks-side cluster spin-up bills inside Databricks and still shows against the pool.
The line most sizing exercises miss hides inside the fourth: idle Joule agents polling for availability consume an estimated five to ten per cent of total tenant capacity with zero active conversations. A model that starts counting at the first question is wrong before the first question.
One configuration trap looks like a capacity shortage and is not. Replication parallelism defaults to eight threads per flow; multiplied across dozens of concurrent flows it saturates the input/output allotment while compute still has headroom.
Decision table: average or peak
Batch-only overnight processing, nobody watching a screen during the spike. Average-based sizing is defensible — the queue costs nothing anyone experiences.
Any live, business-hours interaction: month-end close, a Friday planning cycle, an executive dashboard. Size to peak with a buffer. When a spike exceeds provisioned capacity the tenant queues rather than fails, which is worse for users than a clear error because it simply looks slow.
A peak the business watches while it runs. Size to peak and say so in writing; the credibility cost of a platform that slows exactly when it matters lands on whoever wrote the proposal.
A proposal under commercial pressure. Publish the peak alongside the average. Average-based sizing produces the more attractive figure and systematically under-provisions, because real enterprise usage is not smooth.
A worked example, and the gap it exposes
Use the corpus numbers rather than an invented one. A typical Tier-1 workload pattern lands at roughly 130 to 240 capacity units steady-state and 280 to 360 at peak. The tenant floor is 128.
Read together, the conclusion is uncomfortable and useful: the entry tenant is roughly a third to a half of what a genuine Tier-1 peak needs. Quoting the floor as sufficient is not a small optimism but a dated capacity crisis — and on a tenant at the floor, idle Joule polling alone takes several units before a business query runs.
That is the argument for showing the derivation. A customer who sees the floor, the steady-state band and the peak band together understands why the quote is not the minimum, and procurement moves from "why is this above entry price" to "which workload drives the peak", which both sides can act on.
The costs outside the capacity line
Federation first. Querying an external Snowflake warehouse, an Iceberg lake or an external Databricks workspace live consumes compute on the source platform, billed by that platform. A federation-heavy design can look cheap in the SAP model and expensive on the other invoice, and nothing in the capacity conversation surfaces it.
The same asymmetry runs the other way: every query a Databricks consumer runs against a shared SAP data product consumes reading-side compute. Pipeline elimination is a saving in engineering effort, not in run cost.
Then the labour. Provisioning source data as governed data products is the long pole on most implementations, especially on brownfield estates carrying years of custom fields and inconsistent master data. That is a project cost, not a platform cost, and it belongs in the same business case.
What to ask for in writing
The capacity block being quoted, and the workload breakdown behind it — which of the six consumers was assumed, at what volume. A quote without its derivation cannot be re-argued when the workload changes.
The monitoring and chargeback surface: consumption is reportable per space on a rolling thirty-day basis, which is what lets a platform team attribute cost rather than socialise it.
What happens at the ceiling — queue, throttle or burst, and on what terms. Elastic bursting has been signalled on the roadmap rather than settled commercially, so treat availability as a question to confirm rather than an assumption to price on.
And whether any element is a pass-through from a partner platform, since that portion behaves differently and may sit under a separate contract entirely.
What we cannot assert
We state no price for Business Data Cloud, because SAP publishes none: no per-capacity-unit rate, no entry price, no discount curve, no overflow rate and no Databricks pass-through rate. Figures circulating in the market are estimates from individual deals, and repeating one here would give it the authority of a tariff it does not have.
Frequently asked
Is there a published price list for SAP Business Data Cloud?
No. SAP publishes the capacity-unit model and the tenant minimum, not a rate card. Any specific euro figure you find is a market estimate from a small number of deals, usually quoted without the workload profile that produced it — which is what makes it unusable for sizing your own tenant.
What is the smallest tenant I can buy?
128 capacity units, double the 64-unit floor of a standalone Datasphere tenant. The wider floor reflects the wider workload mix a BDC tenant carries at once — replication, live analytics, planning, Joule grounding and Knowledge Graph traversal against a single pool.
Does the capacity price include the Databricks lakehouse?
In the packaged model the lakehouse is pre-provisioned and billed through SAP, so there is no separate Databricks contract for it. What SAP does not publish is the pass-through rate, so you cannot derive from the capacity model what that portion costs against a direct agreement.
Why is my quote larger than the 128-unit minimum?
Because the minimum is a floor, not a Tier-1 sizing. Corpus patterns for a Tier-1 workload land at roughly 130 to 240 units steady-state and 280 to 360 at peak, and idle Joule polling alone takes an estimated five to ten per cent of the pool before anyone asks a question.
Can I see which team is consuming the capacity?
Yes. Consumption is reported per space on a rolling thirty-day window from the tenant monitor, which is the basis for internal chargeback. Setting it up before go-live is what stops a platform team owning a bill it cannot attribute.
What this page is built on
- BDC Capacity Units (C012)
- SAP Business Data Cloud (BDC) (C009)
- BDC Connect (C015)