SAP Datasphere Spaces Tutorial (Part 1)

A Datasphere Space is the primary organizational and security boundary inside SAP Datasphere. Think of it as a tenant-within-a-tenant: each space gets its own allocated disk and in-memory storage quota, its own set of members with role-based permissions, its own connections to source systems, and its own repository of models, views and data flows. Spaces exist because a single SAP Datasphere tenant is typically shared across many departments (Finance, Sales, Supply Chain, HR reporting) or across environments (Development, Test, Production-like), and without isolation, one team's heavy data load or accidental object deletion could affect everyone else.

Why this matters in real projects: before any modeling work begins, an architect or Datasphere administrator must decide how many spaces to create and what each one represents. Too few spaces (e.g., one giant shared space for the whole company) leads to naming collisions, unclear ownership, difficulty tracking storage consumption per department, and security risk because everyone can see everyone else's tables. Too many spaces (one per report) leads to excessive administrative overhead, duplicated connections, and fragmented data that is hard to govern centrally. The common, sustainable pattern is to align spaces with logical business domains or LOBs (Line of Business), sometimes further split into a landing/staging space and a consumption/reporting space per domain.

Each space is provisioned with a storage allocation (both disk for persisted tables and optionally memory for in-memory views) that is carved out of the tenant's total capacity. This allocation is not automatic magic - a tenant administrator manually assigns GB of disk and memory to each space from the overall tenant pool, and if the pool is exhausted, no new space can be given more until either capacity is purchased or reallocated from another underused space.

Membership and roles are managed per space. A user must be explicitly added as a member of a space before they can see or work with any object inside it, even if they are a global Datasphere administrator conceptually - practical access still flows through space membership and assigned scopes/roles (such as modeler roles that allow creating views versus viewer roles that only allow consumption). This is the first layer of SAP Datasphere's security model, layered underneath more granular object-level and row-level security controls introduced in later, more advanced topics.

Connections (to SAP S/4HANA, SAP BW, non-SAP databases, cloud storage, etc.) are also created and owned at the space level in most scenarios. This means the same physical source system might need a connection defined separately in each space that wants to consume from it, unless a shared/cross-space connection pattern is deliberately designed. Understanding this is essential because new consultants often assume a connection created in one space is automatically visible in another - it is not, by design, because connections carry credentials and access scope tied to that space's security boundary.

Finally, every object a modeler creates - tables, graphical views, entity-relationship models, data flows, task chains - lives inside exactly one space unless it is explicitly shared to another space through the data sharing mechanism (covered in the next lesson). This containment is what makes spaces the fundamental unit of governance, cost tracking, and lifecycle management in SAP Datasphere.

A retail company onboarding SAP Datasphere plans three spaces initially: FIN_SPACE for finance reporting, SALES_SPACE for sales analytics, and a shared STAGING_SPACE where raw extracts from S/4HANA land before being modeled. The Datasphere administrator allocates 200GB disk to STAGING_SPACE (since raw data volumes are large) and smaller allocations to FIN_SPACE and SALES_SPACE, which only hold curated views built on top of shared staging tables via cross-space sharing.

• Creating one large shared space for the entire organization, causing naming conflicts and unclear data ownership
• Assuming a connection made in one space is automatically usable in another space without explicit sharing or a separate connection
• Not adding a user as a space member and then wondering why they cannot see objects that clearly exist in the tenant
• Allocating storage without considering actual data volume estimates, leading to space capacity errors mid-project
• Treating space names as purely cosmetic rather than a long-term governance and reporting boundary that is hard to restructure later

• Design spaces around business domains or clear functional boundaries agreed with stakeholders before any modeling starts
• Reserve a dedicated staging or landing space for raw replicated data separate from curated consumption spaces
• Document space ownership (which team/manager is accountable) alongside its storage allocation
• Plan storage allocation based on realistic data volume and growth estimates, not arbitrary round numbers
• Review space membership periodically as part of access governance, removing users who no longer need access

Interviewers commonly ask candidates to explain the difference between a Datasphere Space and a folder or package in other tools, expecting the answer to cover both storage isolation and security/membership isolation, not just object grouping. Be ready to explain why connections are space-scoped and how that affects design decisions in a multi-team tenant.