Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP Business Data Cloud licensing, and the contracts underneath it

As of 2026-08-14

Business Data Cloud licensing is not a seat count. The commercial unit is a block of capacity units — a bundled measure of compute, memory, storage allotment and throughput sold in tenant-sized blocks — with a floor of 128 units for the smallest tenant against 64 for a standalone semantic-layer tenant. Around that sit separate commercial decisions for every partner platform in the architecture, and those are where procurement conversations actually go wrong.

The unit you are licensing

One 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 and a slice of data-flow throughput. It is a tenant-sizing currency, not a per-user or per-object entitlement, which means the licence conversation and the architecture conversation are the same conversation held twice.

That shapes how a block is defended. Six workload types draw against the same pool — live analytics, replication flows, semantic-model evaluation, agent grounding, knowledge-graph traversal and lakehouse cluster activity — and a block chosen without the workload breakdown behind it cannot be re-argued when one of the six grows.

It also means the licence is consumption-shaped rather than headcount-shaped: adding users adds concurrency against the pool, which surfaces as queuing at peak rather than as a procurement event.

Two commercial models for partner platforms

Every external platform enters under one of two arrangements, and the difference is contractual rather than technical.

A solution extension is a resale. SAP sells the partner's platform under SAP's own contract framework: one purchase order, one support escalation path, one security and compliance review, priced on SAP's terms. Where SAP has already cleared procurement, legal and security as a strategic vendor, that collapses a multi-month vendor-onboarding cycle into an extension of an approved relationship. The cost is negotiating position — an SAP-set ceiling can constrain a customer whose consumption grows fast within the term.

BDC Connect is technical interoperability. The customer holds separate contracts, keeps their own negotiating relationship, and can connect whichever platform they already run.

Both can be held at once on different platforms. That is the intended shape for estates running more than one lakehouse, and a scoping document treating it as either-or at account level will misprice the deal.

The Databricks case and the Snowflake case

Databricks inside the platform is pre-provisioned and billed through SAP, so the customer carries no second agreement for that capacity — a genuine commercial simplification to quote. It is also compatible with keeping an existing Databricks Enterprise agreement for the customer's own workspace, connected through the interoperability service: registering an existing workspace does not require collapsing the existing contract.

Snowflake was announced on two parallel tracks: capacity bought through SAP under the solution extension, and the technical channel that federates the estate either way. In the connected model the commercial relationship stays dual, with pricing in the platform's own credits. Which one a customer wants is a finance conversation — framework discount tiers, projected consumption against a ceiling, whether audit requires a single vendor of record — and none of it touches the architecture.

The field mistake on both is treating the technical and commercial layers as one.

What a data product subscription is, contractually

Subscription is used loosely here, and precision matters because it appears in governance documents that later get audited.

A data product carries an explicit roster of authorised consumers, and consuming teams subscribe rather than querying underlying tables directly; undocumented ad-hoc reads are refused by design. That roster is an access-governance artefact, not a licence line — subscribing a second team to an existing product is not a commercial event.

What it does create is an obligation the other way. The publishing team commits to a stated service level and to a versioning discipline in which a breaking change triggers a ninety-day deprecation cycle. That commitment is what subscribers rely on and what an internal audit will test.

Keep the roster current. A roster accurate at launch and never updated means nobody can say who depends on the product, so every schema decision assumes the worst about the blast radius.

What procurement should ask before signing

Which capacity block is being quoted, and what workload breakdown produced it — without the derivation the block cannot be defended or re-argued.

What happens at the ceiling: queue, throttle or burst, and on what commercial terms. Elastic bursting has been signalled rather than settled, so treat availability as a question rather than an assumption.

Which portions of the quote are pass-through from a partner platform, since those behave differently and may sit under a separate contract.

Whether the partner platforms are entering under a solution extension or under the interoperability service, because that determines vendor count, support path and who the customer negotiates with at renewal.

And how consumption will be reported internally: per-space rolling thirty-day reporting is what lets a platform team attribute cost to the business unit that generated it, rather than owning a bill it cannot explain.

What we cannot assert

SAP publishes no rate card for Business Data Cloud: no per-capacity-unit price, no entry price, no discount curve, no overflow rate, and no published ceiling for the solution-extension model. We therefore describe the contract shapes and the questions that discriminate between them, and state no figure.

Frequently asked

Is Business Data Cloud licensed per user?

No. The commercial unit is a block of capacity units — a bundle of compute, memory, storage allotment and throughput sold in tenant-sized blocks, with a floor of 128 units. Adding users adds concurrency against the pool rather than licence lines, which shows up as queuing at peak rather than as a procurement event.

Do I need a separate Databricks contract?

Not for the lakehouse that ships inside the platform, which is pre-provisioned and billed through SAP. A customer already holding a Databricks Enterprise agreement can keep it and connect that workspace through the interoperability service instead — registering an existing workspace does not require collapsing the existing contract.

Solution extension or BDC Connect, commercially?

A solution extension is a resale: SAP sells the partner platform under one purchase order with one support path, priced on SAP's terms, which simplifies procurement and constrains direct negotiation. BDC Connect leaves the customer with separate contracts and their own negotiating relationship. Both can be held on different platforms.

Does subscribing to a data product cost licence money?

Subscription here is an access-governance artefact rather than a licence line — the consumer roster names which teams may read the product, and adding a team is not a commercial event. What it creates is an obligation on the publisher: a stated service level and a ninety-day deprecation cycle before any breaking change.

What this page is built on

Read next