Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP Datasphere architecture — the four calls that set the cost

As of 2026-08-14

Datasphere is the unified data and semantic layer of SAP's modern analytics estate: federation, replication and modelling in one product, running on HANA Cloud with an integrated Delta Lake. Drawing that is easy. The architecture work is four decisions underneath it, and each one is expensive to reverse once objects exist.

Decision one: which layer owns the semantics

Datasphere models and governs; SAP Analytics Cloud consumes. They are layers, not alternatives, and the real question is how much semantic modelling belongs in each.

The criterion is reuse, not preference. The moment a second story, a planning model, an AI agent or an external tool needs the same measure, the definition has to live where all of them can read it. A key figure defined inside one SAC story is invisible to everything else, and the second consumer re-implements it slightly differently — which is how two dashboards start disagreeing about revenue.

Decision two: federate or load, per object

Federation is first-class here, and that inverts the classical warehouse habit. Historically everything was loaded before it could be modelled; in Datasphere a live query passes through with nothing copied, so loading is a choice you justify rather than a default you inherit.

The justification is one of three things — latency, source-system load, or source availability. Write it down per object, or the team replicates by reflex and pays storage and pipeline maintenance for data nobody queries twice a month.

The reverse mistake is as common. Federating a high-volume fact table under constant query pays the source's live-query cost on every render. Our break-even sits around 100 gigabytes of facts, or fifty concurrent business-intelligence users.

Decision three: how spaces are cut

Every object lives inside a space: a governed partition with its own security, connections and lifecycle, where cross-space consumption goes through the catalog as a versioned data product rather than as ad-hoc table sharing.

Cut on ownership and release cadence — one data owner, one lifecycle. Cutting by project produces a graveyard of ownerless spaces; cutting by source system reproduces the staging layer inside the governance model and makes every useful business object cross a boundary.

Decision four: whether a lakehouse belongs in the picture

Three architectures, and the choice is not about capability. Datasphere alone, consumed by SAP Analytics Cloud — correct whenever nobody on the project would use Spark if you gave it to them, and not the lesser option. Datasphere plus a standalone Databricks, federated — correct when a mature Databricks practice already exists, because migrating it into SAP-native tooling costs more than federating it. Business Data Cloud — the pre-wired bundle, where you buy the integration instead of building it.

The bundle assumes an SAP-majority estate, roughly seventy to eighty percent of analytics-relevant data inside the SAP footprint. Invert that ratio and you are paying SAP packaging to keep a minority of your analytics native.

The first question on all three is not technical: does anyone here operate a lakehouse day to day? Business Data Cloud changes who bills for Databricks, not who has to understand Spark, Delta and Unity Catalog.

The hybrid window is an architecture, not an accident

In almost every multi-year S/4HANA transition, ECC and S/4HANA run side by side for three to five years because lines of business migrate on different cadences. Datasphere's job in that window is to unify analytics across both, so one model layer abstracts which source a number came from.

What keeps it bounded is calendared exit dates per region or line of business, reviewed quarterly. Organisations that design the endgame from the start converge in two to four years; those that treat each decision tactically are still running two platforms seven to ten years later.

Frequently asked

Is SAP Datasphere a replacement for BW?

It is not the new BW, and framing it that way licenses lift-and-shift. What it replaces is a pattern — point-to-point extracts, hand-built warehouses, brittle query layers — with federation, replication and modelling in one governed product.

Do we need SAP Analytics Cloud as well as Datasphere?

For consumption, yes: Datasphere models and governs, SAC delivers stories, applications and planning. Buying only the consumption half is how semantics end up scattered across stories nobody owns.

Federate or replicate by default?

Federate, and justify each replication with latency, source load or source availability. Reverse it past roughly 100 GB of facts or fifty concurrent users, where replication is the cheaper answer.

Where does HANA Cloud fit?

Underneath. Datasphere is the semantic and governance fabric on top of HANA Cloud with an integrated Delta Lake, not a replacement for it. Conflating the two double-counts capacity at sizing time.

What this page is built on

Read next