Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP Datasphere spaces — how to cut them, and what crosses between

As of 2026-08-14

A space is a governed partition with its own security, connections, capacity allocation and lifecycle. Everything in Datasphere lives inside one, and cross-space consumption goes through the catalog as a versioned data product rather than as ad-hoc table sharing. Teams arriving from a shared-schema warehouse read that as bureaucracy. It is precisely the part that stops the shared schema collapsing at the scale it always collapsed at before.

What a space actually bounds

Four things, and the fourth is the one people forget.

Security: space-level roles decide who can open, model in, or administer the space. Connections: source system definitions are scoped to the space that owns them, so two spaces reading the same S/4HANA system do so under their own declared connection. Lifecycle: objects are transported and promoted per space, which is what makes a space the unit of change rather than the unit of storage.

And consumption. This is the structural difference from a schema. A view in space A is not visible to space B because both live in the same tenant; it becomes visible when it is published as a data product with a version, an owner and a contract. Cross-space consumption is a deliberate act with a name attached, which is the whole point.

The fifth thing a space bounds is cost, and it is the one that makes chargeback possible: consumption is measurable per space on a rolling thirty-day basis, which is what a finance team needs to allocate the platform across lines of business.

The decision table: how to cut spaces

If a group of objects shares one data owner and one release cadence → one space. That is the correct primitive: ownership and lifecycle, not subject area.

If two teams need the same measure → do not duplicate it into both spaces. Publish it once as a data product from the space that owns it. The same measure defined in two spaces is not redundancy, it is a scheduled contradiction, and it surfaces as two dashboards disagreeing about revenue.

If you are tempted to create a space per project → stop. Projects end; spaces do not, and you will inherit a graveyard of spaces with no owner and live connections nobody audits.

If you are tempted to create one space per source system → also stop. That reproduces the staging layer inside the governance model and means every business object crosses a space boundary on its way to being useful.

If a line of business will be charged back for its platform consumption → the space boundary has to match the chargeback boundary, decided before go-live. Retrofitting it means re-cutting spaces after the objects exist, which is the expensive version of the same decision.

Space roles are not row-level security, and confusing them is the classic error

There are two questions and they need two mechanisms. Can this user open this object at all — that is the space role, granting viewer, modeller or administrator rights on the space. Which rows of that object may they see — that is a data access control, a filter applied inside an object the user already has access to.

Conflating them is the most common governance design mistake on Datasphere rollouts, and it fails in both directions: either everyone gets a bespoke space to enforce a row filter, or a row filter is trusted to do a job it was never given.

The cost of getting it wrong is countable. A Tier-1 SAP landscape typically ends up with 50 to 200 distinct roles once org-level scope — company code, plant, sales organisation — is cross-multiplied with functional scope and space-level roles. That is the normal, well-designed number. Landscapes that grant a bespoke role per user request rather than mapping to a matrix end up past 500 roles, at which point nobody can audit the estate and every access review becomes archaeology.

The senior move is to build the matrix — business function by system layer by org scope — and get it signed off by the data owner before go-live, then treat every later request as an exception against the matrix rather than as a new precedent.

Two failure modes worth naming in the design review

Spaces used as folders. A team used to a shared schema creates spaces for tidiness, grants everyone access to all of them, and moves on. The governance model is now decorative, the collapse is deferred rather than prevented, and the eventual cleanup happens with production objects in flight.

The permanent staging space. Someone creates a landing space for raw replicated data, everyone gets read access because it is only raw data, and eighteen months later six business-critical models read directly from it, bypassing every semantic definition the platform exists to hold. Raw landing is a legitimate pattern; open access to it is not, and the fix is cheap on day one and expensive on day five hundred.

What we cannot assert

We publish no supported maximum number of spaces per tenant and no per-space capacity limits — those are tenant and contract specific, and belong in SAP's own documentation for your release rather than on a third-party page.

Frequently asked

What is a space in SAP Datasphere?

A governed partition holding its own security, connections, capacity allocation and lifecycle. Every object lives in one, and cross-space consumption goes through the catalog as a versioned data product rather than as ad-hoc table sharing.

How many spaces should we create?

Cut them on ownership and release cadence, not on subject area or project. One data owner and one lifecycle per space is the working rule; a space per project or per source system are the two cuts that reliably go wrong.

How do spaces share data with each other?

Through the catalog, as data products with a version, an owner and a contract. That is deliberately not the same as a shared schema — the sharing is an act with a name attached rather than a side effect of both objects living in the same tenant.

Do space roles control which rows a user sees?

No, and conflating the two is the classic Datasphere governance error. Space roles answer whether a user can open an object; data access controls filter rows inside an object they can already open. You need both, doing different jobs.

What this page is built on

Read next