What Data Federation Means in SAP Datasphere and SAC
Understand the core concept of data federation in the SAP Datasphere and SAC ecosystem, why it exists, and how it differs from replicating data.
Explanation
Data federation is the practice of querying data where it lives, in the source system, instead of copying it into a target analytics or data platform first. In the SAP Datasphere and SAP Analytics Cloud (SAC) context, this matters because organizations often need reporting or modeling on data that is large, frequently changing, governed by strict access rules, or simply too costly to duplicate across every consuming tool. Federation lets Datasphere or SAC send a query to the source at run time and return only the result set needed, rather than storing a full copy. In Datasphere, federation is primarily implemented through remote tables that are set to a 'remote' access type (as opposed to 'replicated', where data is physically pulled into Datasphere's in-memory or persisted storage). A remote table object in Datasphere is a virtual representation of a table sitting in a source system, connected through a defined Connection (for example, to an SAP S/4HANA system, SAP BW/4HANA, or a non-SAP database). When a model or view built on that remote table is queried, Datasphere translates and pushes down as much of the query logic as it can to the source system, then returns results back through the semantic layer. On the SAC side, federation shows up in two related but distinct ways. First, SAC can connect live to SAP BW/4HANA, SAP HANA, or S/4HANA via 'live data connections', where SAC never stores the data locally; every story or analysis query goes straight to the source system in real time. Second, when SAC connects to Datasphere, it can also use a live connection, meaning the data displayed in stories is fetched from Datasphere on demand, and Datasphere itself may in turn be federating from an even more original source. This creates a chain: source system to Datasphere (federated) to SAC (federated), where no full physical copy exists at any layer if fully virtual paths are used. Why would a team choose federation over replication? Reasons include: the source data changes too frequently for a replicated snapshot to stay useful (e.g., real-time operational data); storage costs or governance policies discourage duplicating sensitive data; the data volume is too large to replicate economically; or the source system already has strong query performance and the team wants to avoid double maintenance. The trade-off is that federated queries depend on the source system's availability and performance at query time, and network latency or source system load can directly affect the end-user experience in SAC or Datasphere. A critical beginner-level distinction is between 'remote' and 'replicated' access types for Datasphere remote tables. Remote access performs live pass-through queries. Replicated access copies data into Datasphere on a schedule or in real-time replication mode, so subsequent queries hit the local copy, trading some data freshness guarantees for consistent query performance. Many real projects use a mixed strategy: frequently queried, performance-sensitive tables are replicated, while less frequently accessed or highly volatile tables stay federated. Understanding this foundational concept is essential before diving into connection configuration, performance tuning, or security modeling, because every subsequent decision (which connection type to use, whether to enable data access controls, how to model joins across federated and replicated sources) depends on whether you are dealing with a live pass-through query or a stored copy.
Real project scenario
A retail analytics team needed near real-time inventory visibility across regional S/4HANA systems. Replicating inventory tables every few minutes was rejected due to volume and licensing constraints on storage. The team instead configured Datasphere remote tables with remote access type against each regional S/4HANA system, built a consolidated view on top, and exposed it to SAC via a live data connection. This kept inventory numbers current without duplicating high-volume operational data, at the cost of query response times being tied to each S/4HANA system's load.
Common mistakes
• Assuming 'connecting' a source automatically means data is copied into Datasphere, when in fact the default remote table access type performs live pass-through queries. • Treating federation and replication as interchangeable without evaluating data freshness needs versus query performance needs for the specific use case. • Not accounting for source system load: federated queries add real-time query pressure onto operational systems that may already be busy with transactional workloads. • Overlooking that SAC live connections to Datasphere or BW/4HANA have different feature support (e.g., certain planning or scripting features) compared to import-based models. • Failing to communicate to business users that federated data reflects source-system-availability windows, so if the source system is down for maintenance, reports will fail or show errors.
Best practices
• Default to replication for stable, frequently queried master data or dimension tables where slight staleness is acceptable. • Reserve remote (federated) access for highly volatile or very large fact data where replication is impractical or against governance policy. • Always test federated query performance under realistic concurrent user load before promoting to production, since source system contention is invisible in low-volume testing. • Document for business stakeholders which reports are federated so they understand dependency on source system availability. • Periodically review remote table access type choices as data volumes and usage patterns evolve; a table federated at launch may warrant replication later.
Interview angle
Interviewers often probe whether a candidate understands the practical trade-off between federation and replication, not just the terminology. Be ready to explain a scenario where you chose one over the other, what business or technical constraint drove that decision (data freshness, source system load, storage governance), and what the observed impact was on query performance or user experience. Also expect questions distinguishing SAC live connections versus import connections and how that choice affects available modeling features.