Understanding Data Replication vs Federation in SAP Datasphere
Introduces why Datasphere offers both replicated and federated (virtual) data access, and how to decide which pattern fits a given source and use case.
Explanation
SAP Datasphere connects to source systems such as S/4HANA, SAP ECC, non-SAP databases, and cloud applications through connections that expose remote tables. For each remote table, a consultant chooses between two fundamentally different access patterns: federation (virtual access, sometimes called 'remote' access) and replication (physical copy into Datasphere's persistence layer). In federated access, queries against a remote table are pushed down to the source system at runtime. No data is stored in Datasphere; every report execution triggers a live call to the source. This keeps data perfectly fresh but means query performance depends entirely on the source system's capacity, network latency, and the source's own query optimizer. Federation is attractive when data volumes are small, when near-real-time freshness is mandatory, or when the business does not want a second copy of sensitive data stored outside the source system for compliance reasons. Replication, by contrast, physically copies data from the source into Datasphere's disk or in-memory storage. Once replicated, queries run entirely within Datasphere against the local copy, so performance is decoupled from the source system and from network conditions during report execution. This is essential when: the source system is a transactional system that cannot tolerate heavy analytical query load, the data needs to be combined with other harmonized data in complex models that would be too slow to federate, or when consistent sub-second dashboard performance is required regardless of source system load. The cost of replication is that data is only as fresh as the last replication run, storage consumption increases in Datasphere, and there is an operational responsibility to monitor and maintain the replication job (initial load plus ongoing delta or scheduled refresh). Consultants must also consider governance: replicated data becomes a second copy of the source data, which may trigger data residency, retention, or security review requirements depending on the industry and geography. The decision is made per remote table, not globally, so a single space can mix federated tables (for small reference/master data queried live) with replicated tables (for high-volume transactional data needing performance). Datasphere's remote table object exposes this choice explicitly: an administrator can switch a remote table's access type between 'Remote' and 'Replicated', trigger an initial load, and where the source and connection type support it, enable real-time replication for ongoing delta capture. Understanding this decision framework is the foundation for every later replication topic: connection capability determines which access types are even possible, source system load considerations determine whether real-time replication is advisable, and business freshness requirements determine whether snapshot-based scheduled replication is sufficient versus needing continuous replication.
Real project scenario
A retail customer has a Datasphere space combining live S/4HANA material master (small, federated for freshness) with SAP ECC billing document line items (millions of rows, replicated) to build a margin analysis model. The consultant recommends federation for material master because volumes are small and freshness matters for pricing checks, but replication for billing data because federating tens of millions of rows on every dashboard refresh would overload the ECC production system during business hours.
Common mistakes
• Replicating every remote table by default without evaluating source system impact or actual freshness requirements • Assuming federated access will always be fast enough for high-cardinality joins across large fact tables • Not considering source system load windows before scheduling large initial loads during business hours • Treating replication as a one-time setup and never revisiting the access type as data volume or usage patterns grow • Ignoring data governance implications of creating a persisted copy of sensitive source data
Best practices
• Evaluate access type per remote table based on volume, freshness need, and source system sensitivity, not as a blanket policy • Start with federation for small reference data and switch to replication only when performance testing shows source system strain
Interview angle
Interviewers often ask candidates to justify when they would choose replication over federation for a specific scenario; a strong answer references source system load protection, query performance decoupling, freshness requirements, and storage/governance trade-offs rather than giving a generic 'replication is faster' answer.