Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP Datasphere pricing — how the bill is actually built

As of 2026-08-14

SAP does not publish a Datasphere price list, and anyone quoting you a per-user or per-terabyte figure from a blog is quoting an invention. What is public is the mechanism: Datasphere is sold in capacity units, a bundled measure of compute, memory, storage allotment and throughput, contracted as a tenant-sized block. Understanding the unit is what lets you predict a bill; the discount is negotiated, the arithmetic is not.

What a capacity unit is, and what it buys

One capacity unit is a bundle, not a single resource: roughly one vCPU-equivalent of HANA Cloud compute, about four gigabytes of HANA Cloud memory, a modest storage allotment before overflow pricing applies, and a slice of data-flow throughput.

That bundling is the reason a sizing conversation anchored on vCPU count prices the wrong variable. For in-memory analytics, memory is the dominant cost driver, and a memory-hungry planning model consumes units on a completely different curve from a replication-heavy integration workload with modest memory needs.

Tenant floors are the other public number. A standalone Datasphere tenant starts at 64 capacity units. A Business Data Cloud tenant starts at 128, because it is expected to carry a wider workload mix — replication, live analytics, planning, Joule and the Knowledge Graph — simultaneously. Business Data Cloud entry pricing in the FY26 window has run in the region of €100,000 to €180,000 per year at that floor.

The worked example: why the floor is not the answer

Take a genuine Tier-1 workload. Our sizing guidance puts the steady state at 130 to 240 capacity units and the peak at 280 to 360, against a Business Data Cloud tenant floor of 128. In other words the entry configuration is roughly a third to a half of what a real Tier-1 estate consumes at peak, and quoting the floor as sufficient is how a project arrives at a capacity crisis in month three.

The reason is that peaks are not smooth. A Friday-afternoon financial close or a month-end planning cycle can double normal load for a few hours, and when the spike exceeds provisioned capacity the tenant queues queries rather than failing them — which end users experience as the platform being slow, the worst of the available outcomes.

Add the overhead nobody models: idle Joule agents polling for availability consume five to ten percent of the total pool with zero active conversations. A sizing model that omits it is wrong before the first real question is asked. The defensible default is to size to measured peak plus a twenty percent buffer.

The decision table: how to set the number

If the tenant is batch-only and processes overnight → average-based sizing is defensible. Nobody is watching a screen during the spike, and the queueing cost is invisible.

If there is any live, business-hours user interaction → size to peak plus twenty percent. The credibility damage of a platform that visibly slows down at month-end costs more than the units.

If the workload mix is unknown → do not quote a single number. Quote the six-workload build-up — live SAP Analytics Cloud queries, replication flows, analytic-model evaluation, Joule grounding, Knowledge Graph traversal, and the Databricks side — because a customer who saw the breakdown can see which workload grew; a customer who did not assumes they were oversold.

If procurement wants the smallest possible contracted block → check the elastic bursting roadmap before agreeing. Temporarily exceeding contracted capacity has been in preview with a general-availability target in the second half of 2026, at a burst rate above the contracted rate. That changes the shape of the right answer, and it is a roadmap item, not a shipped guarantee.

If a line of business will be charged back → build it on the tenant monitor's rolling thirty-day per-space consumption, decided before go-live rather than after the first invoice.

The costs that sit outside the capacity-unit line

Federation is billed by the other platform. Querying an external Snowflake warehouse or an Iceberg lake in place consumes compute on that side, on that vendor's invoice. A federation-heavy architecture can be genuinely cheaper in SAP capacity units and more expensive overall, and the capacity-unit conversation will never surface it.

Cross-organisation sharing carries egress. For a representative pattern of ten terabytes shared to five partners, cloud egress has run in the region of two to five hundred US dollars a month — small against the platform, large enough to matter in a chargeback model that pretends it is zero.

A bridged BW estate pays twice. Running BW Bridge consumes Datasphere capacity units plus the embedded BW licence footprint for the duration. Documenting a sunset date in the architecture decision record is the difference between a two-year bridge and a seven-year fixture.

Why no honest page publishes a price

Datasphere and Business Data Cloud are negotiated enterprise contracts. The list rate, the discount, the ramp, the committed term and the bundling with S/4HANA or RISE are all deal-specific, and any published number is either a leaked single data point or an invention with a decimal point.

The €100,000 to €180,000 annual figure above is an entry-level order of magnitude for a Business Data Cloud tenant at the floor in the FY26 window, drawn from our own research ledger. It is a starting point for a budget conversation, not a quote, and it is not a Datasphere-standalone figure.

What you can do without a price list is model the consumption honestly, know your peak, and walk into the negotiation with a workload breakdown. That is the position the number is negotiated from, and it is worth more than a list price you cannot verify.

What we cannot assert

SAP publishes no list price for Datasphere or Business Data Cloud, so no per-user, per-terabyte or per-tenant list rate appears on this page. The €100,000-180,000 entry band is an order of magnitude from our own research ledger for a Business Data Cloud tenant at its floor in the FY26 window — not a quote, not a Datasphere-standalone figure, and not a substitute for a sizing exercise against your own peak.

Frequently asked

How much does SAP Datasphere cost per year?

SAP does not publish it, and no honest page can quote it. Pricing is a negotiated enterprise contract sized in capacity units. As an order of magnitude, Business Data Cloud entry at its 128-unit floor has run around €100,000 to €180,000 a year in the FY26 window by our research ledger.

What is a capacity unit in SAP Datasphere?

A bundle of roughly one vCPU-equivalent of HANA Cloud compute, about four gigabytes of memory, a storage allotment and a slice of throughput. It is the sizing and billing primitive, which is why a tenant is quoted in units rather than in users or terabytes.

What is the minimum SAP Datasphere tenant?

A standalone Datasphere tenant starts at 64 capacity units; a Business Data Cloud tenant starts at 128, because it carries a wider simultaneous workload mix. Neither floor is a realistic Tier-1 configuration.

Is SAP Datasphere priced per user?

No. It is a consumption model sized in capacity units at tenant level, so the cost driver is workload — concurrency, replication volume, memory footprint — rather than headcount. That is why user-count-based estimates from other platforms do not transfer.

What is the most common sizing mistake?

Sizing on average load. Real enterprise usage is not smooth, and month-end can double it for a few hours; when the spike exceeds capacity the tenant queues rather than fails, which users read as the platform being slow. Size to peak plus twenty percent.

What this page is built on

Read next