Concept card

Spaces & Workspaces

As of 2026-07-24T14:00:00Z

Edited by Cédric-Olivier Mâry, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is Spaces & Workspaces?

A Space is a delivery boundary, not an isolation tenant — the whole Datasphere tenant still shares one HANA Cloud pool, one CU budget, one Catalog and one auth model.

What it is

A Space in SAP Datasphere is a logical partition within a tenant that carries its own tables, views, analytic models, hierarchies, currencies, and permissions. It is the fundamental unit of delivery and governance in Datasphere — every object a modeler builds lives inside exactly one Space, owned by one team, with one release cadence.

Why it matters

Space design is the single architectural decision with the longest half-life in a Datasphere program. Get it right and cross-team collaboration flows through clean, versioned contracts; get it wrong and the platform calcifies into either a monolith nobody can safely change, or a maze of point-to-point Space dependencies that makes every schema change a cross-team negotiation. Because Spaces also gate security, cost visibility, and lifecycle ownership, the decision made in week one of a program still shapes how painful year three feels.

How it works

Every Space shares the same underlying HANA Cloud compute, the same tenant-wide Capacity Unit pool, and the same Catalog — Spaces are not isolated tenants, they are governance and delivery boundaries layered on top of shared infrastructure. Cross-Space consumption happens through the Catalog: a producer Space publishes a Data Product, a versioned and documented contract, and a consumer Space subscribes to a read-only association of it. A Space moves through four lifecycle phases — provision, where members and source connections are wired; build, where the modeler populates tables, views, and models; publish, where Data Products are certified and exposed; and maintain, where schema evolution and access reviews happen on an ongoing cadence.

Why it matters in practice

Past four or five functional Spaces, cross-Space sharing typically exceeds 50% of objects — the signal that an org chart got projected onto the platform instead of a delivery model.
Direct Shared Object access between Spaces bypasses the Data Product contract and creates undocumented coupling that breaks the moment the producer team refactors.
The canonical Tier-1 shape is 3-4 functional Spaces plus one Shared Space for master data — mid-market should collapse to 1-2 Spaces, not mirror the enterprise pattern by default.

Key points

Space = delivery boundary (one team, one cadence, one contract). NOT a tenant.
Tier-1 pattern: 3-4 functional Spaces + 1 master-data Shared Space. Above 5 Spaces = smell.
Cross-Space sharing via Data Products in the Catalog — versioned contracts, not Shared Objects.
Space lifecycle: provision (operator-led) → build (delivery-led) → publish (steward-signoff) → maintain (quarterly hygiene).
Four-role permission model: Admin / Modeler / Integrator / Viewer. DAC layers above.
CU pool is tenant-level; per-Space chargeback via Tenant Monitor rolling-30d, not platform-enforced caps.
Multi-region with hard residency = multi-tenant + Delta Sharing federation; not multi-Space inside one tenant.
Quarterly Catalog hygiene clears 30-40% accumulated dead weight in any 2+ year-old Space.
Spaces & Workspaces is mastered only when it changes a named buyer decision.
Start with the semantic contract and control model before demonstrating the tool.

Terms used on this page

Space: Logical delivery boundary in a Datasphere tenant. Owns tables, views, models, permissions for a domain. NOT a tenant.
Shared Space: Space dedicated to cross-cutting master data (Customer, Material, Time, Currency, Cost Centre). Read-by-default for other Spaces.
Data Product: Versioned, documented schema contract published in the Catalog. The canonical cross-Space sharing mechanism.
Catalog: Tenant-wide metadata layer holding semantic types, lineage, Data Products, DAC rules. Sits above all Spaces.
Space Admin: Role that manages Space members + integrations. One per Space, ideally the LoB's data steward.
Modeler: Role that creates and edits objects (tables, views, Analytic Models). 2-4 per Space typical.
Integrator: Role that configures Connections + Replication Flows. 1-2 per Space typical.
Tenant Monitor: Built-in dashboard showing CU consumption per Space, query workload, replication health.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →